From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Andi Kleen <ak@suse.de>, Paul Jackson <pj@sgi.com>,
kenneth.w.chen@intel.com, linux-mm@kvack.org,
linux-ia64@vger.kernel.org
Subject: Re: [NUMA] Display and modify the memory policy of a process through /proc/<pid>/numa_policy
Date: Sat, 16 Jul 2005 00:07:54 +0200 [thread overview]
Message-ID: <20050715220753.GK15783@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0507151450570.11656@schroedinger.engr.sgi.com>
On Fri, Jul 15, 2005 at 02:55:45PM -0700, Christoph Lameter wrote:
> On Fri, 15 Jul 2005, Andi Kleen wrote:
>
> > So for what does that batch monstrosity need to know
> > about the VMAs?
>
> It needs to know where the memory of a process is. Thus
For that the counters I proposed are enough.
> /proc/<pid>/numa_maps.
All it should do is to start processes on specific nodes
(already should work)
and perhaps later migrate processes from some set of specific
nodes to another set of specific nodes (using Ray's page
migration call)
I don't see where a knowledge of specific VMAs is needed anywhere
in this.
>
> > I don't believe any admin will mess with virtual addresses.
>
> No but they will mess with vma's which are only identifiable by the
> starting virtual address.
What for?
>
> > But for "uncooperative" programs working on bigger objects
> > like threads/files/shm areas/processes makes much more sense. And gives
> > much cleaner interfaces too.
>
> Look at the existing patches and you see a huge complexity and heuristics
> because the kernel guesses which vma's to migrate. If the vma are
They kernel doesn't guess, it knows exactly.
> exposed to the batch scheduler / admin then things become much easier to
> implement and the batch scheduler / admin has finer grained control.
So you want to tear up the interface Ray came up with and we discussed
and agreed on and replace it with something completely different and something
that uses this ugly /proc file? I don't think that's a good idea.
>
> > Now I can see some people being interested in more fine grained
> > policy, but the only sane way to do that is to change the source
> > code and use libnuma.
>
> Can libnuma change the memory policy and move pages of existing processes?
If someone hooks it into mbind() sure. But most likely
such changes would be handled by migrate_pages()
>
> > Basically to mess with finegrained virtual addresses you need code access,
> > and when you have that you can as well do it well and add
> > libnuma and recompile.
>
> libnuma is pretty heavy and AFAIK does not have the functionality that is
Heavy??? You're not serious, right?
-Andi
--
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-15 22:07 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-15 1:39 Christoph Lameter
2005-07-15 3:50 ` Paul Jackson
2005-07-15 4:52 ` Chen, Kenneth W
2005-07-15 5:07 ` Christoph Lameter
2005-07-15 5:55 ` Chen, Kenneth W
2005-07-15 6:05 ` Paul Jackson
2005-07-15 11:46 ` Andi Kleen
2005-07-15 16:06 ` Christoph Lameter
2005-07-15 21:04 ` Paul Jackson
2005-07-15 21:12 ` Andi Kleen
2005-07-15 21:20 ` Christoph Lameter
2005-07-15 21:47 ` Andi Kleen
2005-07-15 21:55 ` Christoph Lameter
2005-07-15 22:07 ` Andi Kleen [this message]
2005-07-15 22:30 ` Christoph Lameter
2005-07-15 22:37 ` Andi Kleen
2005-07-15 22:49 ` Christoph Lameter
2005-07-15 22:56 ` Andi Kleen
2005-07-15 23:11 ` Christoph Lameter
2005-07-15 23:44 ` Andi Kleen
2005-07-15 23:56 ` Christoph Lameter
2005-07-16 2:01 ` Andi Kleen
2005-07-16 15:14 ` Christoph Lameter
2005-07-16 22:39 ` Paul Jackson
2005-07-16 23:30 ` Paul Jackson
2005-07-17 1:55 ` Christoph Lameter
2005-07-17 3:50 ` Paul Jackson
2005-07-17 5:56 ` Christoph Lameter
2005-07-17 7:22 ` Paul Jackson
2005-07-17 3:21 ` Christoph Lameter
2005-07-17 4:51 ` Paul Jackson
2005-07-17 6:00 ` Christoph Lameter
2005-07-17 8:17 ` Paul Jackson
2005-07-16 0:00 ` David Singleton
2005-07-16 0:16 ` Steve Neuner
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=20050715220753.GK15783@wotan.suse.de \
--to=ak@suse.de \
--cc=clameter@engr.sgi.com \
--cc=kenneth.w.chen@intel.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