Re: [RFC][PATCH 1/1] Expose per-node reclaim and migration to userspace

["Paul Menage" <menage@google.com>]

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?

> > This would be happening after reclaim has successfully shrunk the
> > in-use memory in a bunch of nodes, and we want to consolidate to a
> > smaller set of nodes.
>
> 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)

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

Paul

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