On 04/11/2014 03:13 PM, David Rientjes wrote:
> What additional information, in your opinion, can we export to assist
> userspace in making this determination that $address is on $nid?
In the case of overlapping nodes, the only place we actually have *all*
of the information is in the 'struct
On Fri, 11 Apr 2014, Dave Hansen wrote:
> > So? Who cares if there are non-addressable holes in part of the span?
> > Ulrich, correct me if I'm wrong, but it seems you're looking for just a
> > address-to-nodeid mapping (or pfn-to-nodeid mapping) and aren't actually
> > expecting that there
On 04/11/2014 04:00 AM, David Rientjes wrote:
> On Thu, 10 Apr 2014, Naoya Horiguchi wrote:
>> > Yes, that's right, but it seems to me that just node_start_pfn and
>> > node_end_pfn
>> > is not enough because there can be holes (without any page struct backed)
>> > inside
>> > [node_start_pfn,
On Thu, 10 Apr 2014, Naoya Horiguchi wrote:
> Yes, that's right, but it seems to me that just node_start_pfn and
> node_end_pfn
> is not enough because there can be holes (without any page struct backed)
> inside
> [node_start_pfn, node_end_pfn), and it's not aware of memory hotplug.
>
So?
On Thu, 10 Apr 2014, Naoya Horiguchi wrote:
Yes, that's right, but it seems to me that just node_start_pfn and
node_end_pfn
is not enough because there can be holes (without any page struct backed)
inside
[node_start_pfn, node_end_pfn), and it's not aware of memory hotplug.
So? Who
On 04/11/2014 04:00 AM, David Rientjes wrote:
On Thu, 10 Apr 2014, Naoya Horiguchi wrote:
Yes, that's right, but it seems to me that just node_start_pfn and
node_end_pfn
is not enough because there can be holes (without any page struct backed)
inside
[node_start_pfn, node_end_pfn),
On Fri, 11 Apr 2014, Dave Hansen wrote:
So? Who cares if there are non-addressable holes in part of the span?
Ulrich, correct me if I'm wrong, but it seems you're looking for just a
address-to-nodeid mapping (or pfn-to-nodeid mapping) and aren't actually
expecting that there are no
On 04/11/2014 03:13 PM, David Rientjes wrote:
What additional information, in your opinion, can we export to assist
userspace in making this determination that $address is on $nid?
In the case of overlapping nodes, the only place we actually have *all*
of the information is in the 'struct
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
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
On Tue, 8 Apr 2014, Naoya Horiguchi wrote:
> memory hotplug is done in memory block basis, so if we get info from under
> /sys/devices/system/memory/memory it should be memory hotplug-aware
> (/sys/devices/system/memory/memory/state shows online/offline status.)
>
> And IIUC, "pfn-node_id"
On Tue, 8 Apr 2014, Naoya Horiguchi wrote:
memory hotplug is done in memory block basis, so if we get info from under
/sys/devices/system/memory/memoryID it should be memory hotplug-aware
(/sys/devices/system/memory/memoryID/state shows online/offline status.)
And IIUC, pfn-node_id mapping
On Mon, Mar 31, 2014 at 9:24 PM, Naoya Horiguchi
wrote:
> The information about "pfn-node" mapping seldom (or never) changes after boot,
> so it seems better to me that adding a new interface somewhere under
> /sys/devices/system/node/nodeN which shows pfn range of a given node.
> If this doesn't
On Mon, Mar 31, 2014 at 9:24 PM, Naoya Horiguchi
n-horigu...@ah.jp.nec.com wrote:
The information about pfn-node mapping seldom (or never) changes after boot,
so it seems better to me that adding a new interface somewhere under
/sys/devices/system/node/nodeN which shows pfn range of a given
On Mon, 31 Mar 2014, Naoya Horiguchi wrote:
> > I might be missing something but I couldn't find a way to use the
> > pagemap information to then look up the NUMA node the respective page is
> > located on. Especially when analyzing anomalities this is really
> > useful. The /proc/kpageflags
I might be missing something but I couldn't find a way to use the
pagemap information to then look up the NUMA node the respective page is
located on. Especially when analyzing anomalities this is really
useful. The /proc/kpageflags and /proc/kpagecount files don't have that
information.
If
I might be missing something but I couldn't find a way to use the
pagemap information to then look up the NUMA node the respective page is
located on. Especially when analyzing anomalities this is really
useful. The /proc/kpageflags and /proc/kpagecount files don't have that
information.
If
On Mon, 31 Mar 2014, Naoya Horiguchi wrote:
I might be missing something but I couldn't find a way to use the
pagemap information to then look up the NUMA node the respective page is
located on. Especially when analyzing anomalities this is really
useful. The /proc/kpageflags and
18 matches
Mail list logo
