From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Davidlohr Bueso <davidlohr.bueso@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: add node physical memory range to sysfs
Date: Wed, 12 Dec 2012 20:49:14 -0800 [thread overview]
Message-ID: <50C95E4A.9010509@linux.vnet.ibm.com> (raw)
In-Reply-To: <1355364222.9244.3.camel@buesod1.americas.hpqcorp.net>
On 12/12/2012 06:03 PM, Davidlohr Bueso wrote:
> On Wed, 2012-12-12 at 17:48 -0800, Dave Hansen wrote:
>> But if we went and did it per-DIMM (showing which physical addresses and
>> NUMA nodes a DIMM maps to), wouldn't that be redundant with this
>> proposed interface?
>
> If DIMMs overlap between nodes, then we wouldn't have an exact range for
> a node in question. Having both approaches would complement each other.
How is that possible? If NUMA nodes are defined by distances from CPUs
to memory, how could a DIMM have more than a single distance to any
given CPU?
>> How do you plan to use this in practice, btw?
>
> It started because I needed to recognize the address of a node to remove
> it from the e820 mappings and have the system "ignore" the node's
> memory.
Actually, now that I think about it, can you check in the
/sys/devices/system/ directories for memory and nodes? We have linkages
there for each memory section to every NUMA node, and you can also
derive the physical address from the phys_index in each section. That
should allow you to work out physical addresses for a given node.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Davidlohr Bueso <davidlohr.bueso@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: add node physical memory range to sysfs
Date: Wed, 12 Dec 2012 20:49:14 -0800 [thread overview]
Message-ID: <50C95E4A.9010509@linux.vnet.ibm.com> (raw)
In-Reply-To: <1355364222.9244.3.camel@buesod1.americas.hpqcorp.net>
On 12/12/2012 06:03 PM, Davidlohr Bueso wrote:
> On Wed, 2012-12-12 at 17:48 -0800, Dave Hansen wrote:
>> But if we went and did it per-DIMM (showing which physical addresses and
>> NUMA nodes a DIMM maps to), wouldn't that be redundant with this
>> proposed interface?
>
> If DIMMs overlap between nodes, then we wouldn't have an exact range for
> a node in question. Having both approaches would complement each other.
How is that possible? If NUMA nodes are defined by distances from CPUs
to memory, how could a DIMM have more than a single distance to any
given CPU?
>> How do you plan to use this in practice, btw?
>
> It started because I needed to recognize the address of a node to remove
> it from the e820 mappings and have the system "ignore" the node's
> memory.
Actually, now that I think about it, can you check in the
/sys/devices/system/ directories for memory and nodes? We have linkages
there for each memory section to every NUMA node, and you can also
derive the physical address from the phys_index in each section. That
should allow you to work out physical addresses for a given node.
next prev parent reply other threads:[~2012-12-13 4:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 22:34 [PATCH] mm: add node physical memory range to sysfs Davidlohr Bueso
2012-12-07 22:34 ` Davidlohr Bueso
2012-12-07 23:51 ` Andrew Morton
2012-12-07 23:51 ` Andrew Morton
2012-12-08 0:17 ` Dave Hansen
2012-12-08 0:17 ` Dave Hansen
2012-12-13 1:18 ` Davidlohr Bueso
2012-12-13 1:18 ` Davidlohr Bueso
2012-12-13 1:48 ` Dave Hansen
2012-12-13 1:48 ` Dave Hansen
2012-12-13 2:03 ` Davidlohr Bueso
2012-12-13 2:03 ` Davidlohr Bueso
2012-12-13 4:49 ` Dave Hansen [this message]
2012-12-13 4:49 ` Dave Hansen
2012-12-13 15:17 ` KOSAKI Motohiro
2012-12-13 15:17 ` KOSAKI Motohiro
2012-12-13 23:15 ` Davidlohr Bueso
2012-12-13 23:15 ` Davidlohr Bueso
2012-12-14 0:18 ` Dave Hansen
2012-12-14 0:18 ` Dave Hansen
2012-12-08 19:45 ` Greg Kroah-Hartman
2012-12-08 19:45 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50C95E4A.9010509@linux.vnet.ibm.com \
--to=dave@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=davidlohr.bueso@hp.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.