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 17:48:25 -0800 [thread overview]
Message-ID: <50C933E9.2040707@linux.vnet.ibm.com> (raw)
In-Reply-To: <1355361524.5255.9.camel@buesod1.americas.hpqcorp.net>
On 12/12/2012 05:18 PM, Davidlohr Bueso wrote:
> On Fri, 2012-12-07 at 16:17 -0800, Dave Hansen wrote:
>> Seems like the better way to do this would be to expose the DIMMs
>> themselves in some way, and then map _those_ back to a node.
>
> Good point, and from a DIMM perspective, I agree, and will look into
> this. However, IMHO, having the range of physical addresses for every
> node still provides valuable information, from a NUMA point of view. For
> example, dealing with node related e820 mappings.
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?
How do you plan to use this in practice, btw?
--
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 17:48:25 -0800 [thread overview]
Message-ID: <50C933E9.2040707@linux.vnet.ibm.com> (raw)
In-Reply-To: <1355361524.5255.9.camel@buesod1.americas.hpqcorp.net>
On 12/12/2012 05:18 PM, Davidlohr Bueso wrote:
> On Fri, 2012-12-07 at 16:17 -0800, Dave Hansen wrote:
>> Seems like the better way to do this would be to expose the DIMMs
>> themselves in some way, and then map _those_ back to a node.
>
> Good point, and from a DIMM perspective, I agree, and will look into
> this. However, IMHO, having the range of physical addresses for every
> node still provides valuable information, from a NUMA point of view. For
> example, dealing with node related e820 mappings.
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?
How do you plan to use this in practice, btw?
next prev parent reply other threads:[~2012-12-13 1:48 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 [this message]
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
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=50C933E9.2040707@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.