Messages in this thread | | | Date | Thu, 10 Apr 2014 15:06:49 -0700 (PDT) | From | David Rientjes <> | Subject | Re: NUMA node information for pages |
| |
On Wed, 9 Apr 2014, Naoya Horiguchi wrote:
> > [ And that block_size_bytes file is absolutely horrid, why are we > > exporting all this information in hex and not telling anybody? ] > > Indeed, this kind of implicit hex numbers are commonly used in many place. > I guess that it's maybe for historical reasons. >
I think it was meant to be simple to that you could easily add the length to the start, but it should at least prefix this with `0x'. That code has been around for years, though, so we probably can't fix it now.
> > I'd much prefer a single change that works for everybody and userspace can > > rely on exporting accurate information as long as sysfs is mounted, and > > not even need to rely on getpagesize() to convert from pfn to physical > > address: just simple {start,end}_phys_addr files added to > > /sys/devices/system/node/nodeN/ for node N. Online information can > > already be parsed for these ranges from /sys/devices/system/node/online. > > OK, so what if some node has multiple address ranges? I don't think that > start(end)_phys_addr simply returns minimum (maximum) possible address is optimal, > because users can't know about void range between valid address ranges > (non-exist pfn should not belong to any node). > Are printing multilined (or comma-separated) ranges preferable for example > like below? > > $ cat /sys/devices/system/node/nodeN/phys_addr > 0x0-0x80000000 > 0x100000000-0x180000000 >
What the...? nodeN should represent the pgdat for that node and a pgdat can only have a single range. I'm suggesting that /sys/devices/system/node/nodeN/start_phys_addr returns node_start_pfn(N) << PAGE_SHIFT and /sys/devices/system/node/nodeN/end_phys_addr returns node_end_pfn(N) << PAGE_SHIFT and prefix them correctly this time with `0x'.
| |