linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@engr.sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: kenneth.w.chen@intel.com, linux-mm@kvack.org,
	linux-ia64@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [NUMA] Display and modify the memory policy of a process through /proc/<pid>/numa_policy
Date: Fri, 15 Jul 2005 09:06:25 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.62.0507150901500.8556@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20050714230501.4a9df11e.pj@sgi.com>

On Thu, 14 Jul 2005, Paul Jackson wrote:

> Christoph wrote:
> > This is an implementation that deals with monitoring and managing running 
> > processes.
> 
> So is this patch roughly equivalent to adding a pid to the
> mbind/set_mempolicy/get_mempolicy system calls?

Yes. Almost.
 
> Not that I am advocating for or against adding doing that.  But this
> seems like alot of code, with new and exciting API details, just to
> add a pid argument, if such it be.

I think the syscall interface is plainly wrong for monitoring and managing 
a process. The /proc interface is designed to monitor processes and it 
allows the modification of process characteristics. This is the natural 
way to implement viewing of numa allocation maps, the runtime changes
to allocation strategies and finally something that migrates pages of a 
vma between nodes.

A syscall interface implies that you have to write user space programs 
with associated libraries to display and manipulate values. As 
demonstrated this is really not necessary. Implementation via /proc
is fairly simple.
--
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>

  parent reply	other threads:[~2005-07-15 16:06 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 [this message]
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
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=Pine.LNX.4.62.0507150901500.8556@schroedinger.engr.sgi.com \
    --to=clameter@engr.sgi.com \
    --cc=ak@suse.de \
    --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