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

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

On 11/29/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> Yes, but when you migrate tasks between these containers, or when you
> create/destroy them, then why can't you do the migration at that time?

?

The migration that I'm envisaging is going to occur when either:

- we're trying to move a job to a different real numa node because,
say, a new job has started that needs the whole of a node to itself,
and we need to clear space for it.

- we're trying to compact the memory usage of a job, when it has
plenty of free space in each of its nodes, and we can fit all the
memory into a smaller set of nodes.

Neither of these are tied to create/destroy time or moving processes
in/out of jobs (in fact we'd not be planning to move processes between
jobs - once a process is in a job it would stay there, although I
realise other people would have different requirements).

> > I don't think it would - keeping as much of the code as possible in
> > userspace makes development and deployment much faster. We don't
> > really have any higher-level APIs at this point - just userspace
> > middleware manipulating cpusets.
>
> We can't use that as an argument for the upstream kernel, but I
> would believe that it is a good choice for google.
>

I would have thought that providing userspace just enough hooks to do
what it needs to do, and not mandating higher-level constructs is
exactly the philosophy of the linux kernel. Hence, e.g. providing
efficient building blocks like sendfile and a threaded network stack,
faster therading with NPTL and a very limited static-file webserver
(TUX, even though it's not in the mainline) and leaving the complex
bits of webserving to userspace.

Things like deciding which containers should be using which nodes, and
directing the kernel appropriately, is the job of userspace, not
kernelspace, since there are lots of possible ways of making those
decisions.

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>