On Jan 19, 2010, at 3:20 AM, Brice Goglin wrote:
> I propose the following changes to the object attributes. struct
> hwloc_obj now contains a struct hwloc_memory pointer:
Is there any reason not to make this a sub-struct included in hwloc_obj (vs. a
pointer that requires an additional malloc)? I'm not saying that malloc
performance and/or the cost of dereferencing the pointer is a big deal -- it
just feels "un-tidy" to have another malloc for something that will be used in
many situations.
> struct hwloc_memory {
> unsigned long total_kB; /* Total memory in this object and its children */
> unsigned long local_kB; /* Local memory in this object */
FWIW, I'm not wild about the capitol "B" at the end, but that's mainly because
I'm lazy. ;-) How about total_mem and local_mem, and we specify that they are
in units of bytes?
I say "bytes" instead of "kilobytes" because it might be easier to avoid
getting into the "what does kilo mean -- 1000 or 1024?" arguments.
Also, do we want to make them uint64_t's? A system's total memory could get
pretty large -- more than 4B bytes on 32 bit systems...? Hmm. I'm indecisive
on this one -- I can think of reasons for and against... I guess I just prefer
future-proofing as much as possible.
> struct hwloc_memory_pages {
> unsigned long size;
> unsigned long count;
> } * local_pages; /* 0-terminated array of pages or hugepages sizes and
> counts */
> }
In the worst case, we've added 2*sizeof(long)+sizeof(struct*) to the size of
the hwloc_obj struct for objects that don't have memory. But I don't think
that's a big deal, right?
> This obj->memory could be NULL except for Node, Machine and maybe
> System.
Or maybe just total and local memory set to 0?
> > I'd say it can be valuable to support key=value pairs on any object so
> > that future object types can be extensible (e.g., vendor pci devices).
> > But common stuff should be accessible as struct members so that
> > there's no string parsing needed (I'm no doubt just voicing what we
> > all already think). I.e., esoteric stuff can start as a key=value
> > strings but as they get mature / popular, they can "graduate" to
> > become a struct member.
>
> If we do the above, Node and System won't have any specific attribute
> anymore. Machine will still have DMI infos. But I am not sure they are
> common enough and deserve an actual struct field, they could stay in the
> array of stringified info.
I'm not sure I understand what you mean here -- are you thinking of moving the
DMI fields to the general key=value arrays? What is "DMI"?
> Actually, maybe obj->name should go there as well before it mixes to
> many meanings. It's mostly unused in trunk, except to store "Kerrighed"
> since very recently. We talked about using it to store the hostname of
> Machine objects. And the libpci branch uses it to store the PCI
> vendor/model string and OS device names. Maybe all these shouldn't be in
> obj->name and rather in the array of strings as OSName=Kerrighed,
> Hostname=foobar, PCIVendor=foo, PCIModel=bar, OSDevice=eth2, ...
How about both? It can be useful to have a simple/common field to print a
human-readable text field (even if it's only a summary and the real details are
in key=value pairs).
--
Jeff Squyres
jsquy...@cisco.com
