Perhaps we should distinguish between memory in this object and memory that is accessible by this object...?

I.e., cache and numa node can have x local memory. System/machine may have 0 local memory but (sum of children) accessible memory.


1 I think it is a common enough action to want to know how much memory there is on a machine/system that hwloc should do the sum.

2 maybe local-kb can be an attribute of relevant objects, but total-kb can be an attribute of machine/system/whatever (i.e., anything that can have children that have local-kb). This keeps the values and meanings separate.

Sent from my PDA.  No type good.

----- Original Message -----
From: <>
To: hwloc development <>
Sent: Wed Jan 13 08:40:49 2010
Subject: [hwloc-devel] memory size attributes


While cleaning the System/Machine root types, I wondered what we
actually want to store in memory_kB attributes. It looks obvious for
Caches and NUMA nodes. But I am not sure about Machines and Systems.

If we have a machine with 2 NUMA nodes, should the machine memory size
be the sum the sizes of both NUMA node sizes? Or should it be 0 since
the machine has no memory except in NUMA nodes? Same question for a
Kerrighed system assembling 2 machines.

Then, if we have 1 Misc object grouping some NUMA nodes that are close
to each other: Should we store the total memory size of these nodes in
the Misc object attribute as well? We have the total memory size in the
NUMA node object (below misc) and in the machine object (above misc),
why not in Misc too? I am not saying that I want it, I am saying that
it's not very consistent.

So I wonder if we should just not sum anymore and let the application do
the math when it actually needs the sum. A quick helper with
get_next_obj_by_type( ... NODE) would work.

Or we need to document memory size attributes better:
* NUMA node: set of memory that can be accessed with the same access
time from other objects
* machine: set of cache-coherent memory, can be made of multiple NUMA nodes
* system: set of memory that is virtually accessible, but may not be


hwloc-devel mailing list