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 04:01:41 +0200 [thread overview]
Message-ID: <20050716020141.GO15783@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0507151647300.12832@schroedinger.engr.sgi.com>
> One always needs control over what is migrated. Ideally one would be able
> to specify that only the vma containing the huge amount of sparsely
> accessed data is to be migrated if memory becomes tight but the process
> continues to run on the same node. The stack and text segments and
> libraries should stay on the node.
There is no way to do sane locking from user space
for such external manipulation of arbitary mappings. You need
to do it in the kernel.
BTW all your talking about VMAs is useless here anyways because
NUMA policies don't necessarily match VMAs and neither does
allocated memory.
> Are you willing to allow us to control memory placement? Or will it be
> automatically? If automatically then maybe you need to get rid of libnuma
> and numactl and put it all in the scheduler. Otherwise please full control
> and not some half-way measures.
Without my NUMA policy code you wouldn't have any usable NUMA policy today,
But my goal is definitely to keep the kernel interfaces for this
clean. And what you're proposing is *not* clean.
I think the per VMA approach is fundamentally wrong because
virtual addresses are nothing an external user can safely
access. Doing it on higher level objects allows better interfaces
and better locking, and as far as I can see process/shm segment/file
are the only useful objects for this.
It should basically work like swapping without the need to SIGSTOP
the target.
-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-16 2:01 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
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 [this message]
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=20050716020141.GO15783@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