From: Dave Hansen <haveblue@us.ibm.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: linux-mm <linux-mm@kvack.org>,
ia64 list <linux-ia64@vger.kernel.org>,
pj@sgi.com
Subject: Re: [NUMA] /proc/<pid>/numa_maps to show on which nodes pages reside
Date: Mon, 11 Jul 2005 13:31:15 -0700 [thread overview]
Message-ID: <1121113875.15095.45.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.62.0507111058270.21618@schroedinger.engr.sgi.com>
On Mon, 2005-07-11 at 11:02 -0700, Christoph Lameter wrote:
> On Mon, 11 Jul 2005, Dave Hansen wrote:
>
> > So, if something like numa_maps existed, but pointed to the memory
> > object instead of the NUMA node directly, you could still easily derive
> > the NUMA node. But, you'd also get information about which particular
> > bits of memory are being used. That might be useful for a user that's
> > getting desperate to remove some memory and wants to kill some processes
> > that might be less than willing to release that memory.
>
> We really need both I guess. If you dealing with a batch scheduler that
> wants to move memory around between nodes in order to optimize programs
> then you nedd to have numa_maps. Maybe we need to have two: numa_maps
> and memory_maps?
Well, my point was that, if we have two, the numa_maps can be completely
derived in userspace from the information in memory_maps plus sysfs
alone. So, why increase the kernel's complexity with two
implementations that can do the exact same thing? Yes, it might make
the batch scheduler do one more pathname lookup, but that's not the
kernel's problem :)
BTW, are you planning on using SPARSEMEM whenever NUMA is enabled in the
future?
-- Dave
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-07-11 20:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-08 21:11 Christoph Lameter
2005-07-11 17:20 ` Dave Hansen
2005-07-11 18:02 ` Christoph Lameter
2005-07-11 20:31 ` Dave Hansen [this message]
2005-07-11 21:16 ` Christoph Lameter
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=1121113875.15095.45.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=clameter@engr.sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pj@sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox