linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Paul Menage <menage@google.com>
Cc: linux-mm@kvack.org, akpm@osdl.org
Subject: Re: [RFC][PATCH 1/1] Expose per-node reclaim and migration to userspace
Date: Thu, 30 Nov 2006 20:21:16 +1100	[thread overview]
Message-ID: <456EA28C.8070508@yahoo.com.au> (raw)
In-Reply-To: <6599ad830611300106w5f5deb60q6d83a684fd679d06@mail.gmail.com>

Paul Menage wrote:
> On 11/30/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>> >
>> > Being able to say "try to move all memory from this node to this other
>> > set of nodes" seems like a generically useful thing even for other
>> > uses (e.g. hot unplug, general HPC numa systems, etc).
>>
>> AFAIK they do that in their higher level APIs (at least HPC numa does).
> 
> 
> Could you point me at an example?

kernel/cpuset.c:cpuset_migrate_mm

>> So your API could be some directive to consolidate? You could get
>> pretty accurate estimates with page statistics, as to whether it
>> can be done or not.
> 
> 
> Yes, and exposing those statistics (already available in
> /sys/device/system/node/node*/meminfo) and the low-level mechanism for
> migration are, to me, things that are appropriate for the kernel. I'm
> not sure what a specific "consolidation API" would look like, beyond
> the API that I'm already proposing (migrate memory from node X to
> nodes A,B,C)

How about "try to change the memory reservation charge of this
'container' from xMB to yMB"? Underneath that API, your fakenode
controller would do the node reclaim and consolidation stuff --
but it could be implemented completely differently in the case of
a different type of controller.

>> The cpusets code is definitely similar to what memory resource control
>> needs. I don't think that a resource control API needs to be tied to
>> such granular, hard limits as the fakenodes code provides though. But
>> maybe I'm wrong and it really would be acceptable for everyone.
> 
> 
> Ah. This isn't intended to be specifically a "resource control API".
> It's more intended to be an API that could be useful for certain kinds
> of resource control, but could also be generically useful.

If it is exporting any kind of implementation details, then it needs
to be justified with a specific user that can't be implemented in a
better way, IMO.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
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>

  reply	other threads:[~2006-11-30  9:21 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29  3:06 [RFC][PATCH 0/1] Node-based reclaim/migration menage
2006-11-29  3:06 ` [RFC][PATCH 1/1] Expose per-node reclaim and migration to userspace menage
2006-11-29  6:07   ` Nick Piggin
2006-11-29 21:57     ` Paul Menage
2006-11-30  4:13       ` Christoph Lameter
2006-11-30  4:18         ` Paul Menage
2006-11-30  7:38       ` Nick Piggin
2006-11-30  7:57         ` Paul Menage
2006-11-30  8:26           ` Nick Piggin
2006-11-30  8:39             ` Paul Menage
2006-11-30  8:55               ` Nick Piggin
2006-11-30  9:06                 ` Paul Menage
2006-11-30  9:21                   ` Nick Piggin [this message]
2006-11-30  9:45                     ` Paul Menage
2006-11-30 10:15                       ` Nick Piggin
2006-11-30 10:40                         ` Paul Menage
2006-11-30 11:04                           ` Nick Piggin
2006-11-30 11:23                             ` Paul Menage
2006-11-30 11:35                               ` Nick Piggin
2006-11-30  0:18   ` KAMEZAWA Hiroyuki
2006-11-30  0:25     ` Paul Menage
2006-11-30  0:38       ` KAMEZAWA Hiroyuki
2006-11-30  4:15       ` Christoph Lameter
2006-11-30  4:10   ` Christoph Lameter
2006-11-30  0:31 ` [RFC][PATCH 0/1] Node-based reclaim/migration KAMEZAWA Hiroyuki
2006-11-30  0:31   ` Paul Menage
2006-11-30  4:11     ` KAMEZAWA Hiroyuki
2006-11-30  4:17     ` Christoph Lameter
2006-11-30 10:45       ` Paul Menage
2006-11-30 11:12         ` KAMEZAWA Hiroyuki
2006-11-30 11:25           ` Paul Menage
2006-11-30 12:18             ` KAMEZAWA Hiroyuki
2006-11-30 18:28             ` Christoph Lameter
2006-11-30 18:35               ` Paul Menage
2006-11-30 18:39                 ` Christoph Lameter
2006-11-30 19:09                   ` Paul Menage
2006-11-30 19:42                     ` Christoph Lameter
2006-11-30 19:53                       ` Paul Menage
2006-11-30 20:00                         ` Christoph Lameter
2006-11-30 20:07                           ` Paul Menage
2006-11-30 20:15                             ` Christoph Lameter
2006-11-30 21:33                               ` Paul Menage
2006-11-30 23:41                                 ` Christoph Lameter
2006-11-30 23:48                                   ` Paul Menage
2006-12-01  2:23                                     ` Christoph Lameter
2006-12-01 19:32                                       ` Paul Menage
2006-12-01 19:56                                         ` Christoph Lameter
2006-12-01  2:44                                     ` KAMEZAWA Hiroyuki
2006-12-01  2:43                                       ` Christoph Lameter
2006-12-01  2:59                                         ` KAMEZAWA Hiroyuki
2006-12-01  2:44                                       ` Christoph Lameter
2006-12-01  3:10                                         ` KAMEZAWA Hiroyuki
2006-12-01  5:28                                           ` Christoph Lameter
2006-11-30  4:04 ` 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=456EA28C.8070508@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    --cc=menage@google.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