On 11/19/2018 11:07 PM, Dave Hansen wrote: > On 11/18/18 9:44 PM, Anshuman Khandual wrote: >> IIUC NUMA re-work in principle involves these functional changes >> >> 1. Enumerating compute and memory nodes in heterogeneous environment (short/medium term) > > This patch set _does_ that, though. > >> 2. Enumerating memory node attributes as seen from the compute nodes (short/medium term) > > It does that as well (a subset at least). > > It sounds like the subset that's being exposed is insufficient for yo > We did that because we think doing anything but a subset in sysfs will > just blow up sysfs: MAX_NUMNODES is as high as 1024, so if we have 4 > attributes, that's at _least_ 1024*1024*4 files if we expose *all* > combinations. Each permutation need not be a separate file inside all possible NODE X (/sys/devices/system/node/nodeX) directories. It can be a top level file enumerating various attribute values for a given (X, Y) node pair based on an offset something like /proc/pid/pagemap. > > Do we agree that sysfs is unsuitable for exposing attributes in this manner? > Yes, for individual files. But this can be worked around with an offset based access from a top level global attributes file as mentioned above. Is there any particular advantage of using individual files for each given attribute ? I was wondering that a single unsigned long (u64) will be able to pack 8 different attributes where each individual attribute values can be abstracted out in 8 bits.
