Perhaps consider renaming NUMAs

[rhc54]

Would it make sense for HWLOC to rename NUMAs according to their actual origin? In other words, instead of calling everything a "NUMANODE", perhaps label the objects as "CPUNUMA", "GPUNUMA", "FABRICNUMA", etc?

It seems we know this separation from the source data. Labeling the objects accordingly would make the nature of the memory clearer to users and thereby reduce the chances for misuse. I included "fabric" in there because we already had one example of fabric integrated into the package before the EU ruling against the manufacturer, but that will return at some point. I imagine other things will eventually make their way into the package as well.

[bgoglin]

We already set the obj->subtype field of NVIDIA GPUs nodes "GPUMemory" (since hwloc 2.1, when identification of these nodes was added). I would like to do it for other kinds but there's no standardized way yet.

For KNL, we named MCDRAM nodes "MCDRAM" because we could hardwire things easily. For upcoming DRAM+HBM platforms from Intel and ARM, I don't know if we'll be able to detect them easily :/

Last time I asked, kernel people didn't want to tell us that a node is non-volatile-memory-backed (because they don't want us to assume that NV memory is always slower than DRAM). We already detect that a node comes a "DAX device", which basically tells us it's NVDIMM. I didn't set obj->subtype for these nodes yet, because there are ways to lie by exposing DRAM as NVDIMM, but that's a kernel hacker corner case that I may ignore.

[rhc54]

Guess I was looking for the obj->type to be set so that we could use the current "get info by type" functions, removing the need for people to write the code to filter things (like I did). I think it would be nice if we could identify the type of RAM involved, but I'd settle for differentiating it by function.

If we look at the current (and at least mid-term future) package, it contains one or more CPU chips plus one or more memory chips. We can also expect it to contain a modestly capable GPU chip and possibly a fabric chip. The CPU, GPU, and fabric chips will almost certainly have on-board memory as well (for the CPU, beyond the current L1/2/3 caches). What we need is some user-friendly way of saying "I want the Nth CPU-usable NUMA" - i.e., ignoring the GPU and fabric memory. Or "I want the Mth GPU NUMA region", perhaps specifying a particular GPU of interest.

It would be nice if HWLOC consumers didn't have to write all that code. Hence my suggestion about creating new object types so the current APIs can provide the support. Of course, I guess you could always write new APIs that searched object type and subtype - don't know if that is easier or not. Either way, definitely want it to be efficient as this is an operation that gets done many, many times when mapping a large-scale application.