[lkml]   [2005]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Andi wrote:
> I still think it's fundamentally unclean and racy. External processes
> shouldn't mess with virtual addresses of other processes.

It's not really messing with (changing) the virtual addresses of
another process. It's messing with the physical placement. It's
using the virtual addresses to help choose which pages to move.

Do you have any better way to suggest, Andi, for a batch manager to
relocate a job? The typical scenario, as Ray explained it to me, is
thus. A lower priority job, after running a while, is displaced by a
higher priority job that needs a large number of nodes. Later on enough
nodes to run the lower priority job become available elsewhere. The
lower priority job can either continue to wait for its original nodes to
come free (after the high priority job finishes) or it can be relocated
to the nodes available now.

How would you recommend that the batch manager move that job to the
nodes that can run it? The layout of allocated memory pages and tasks
for that job must be preserved in order to keep the same performance.
The migration method needs to scale to hundreds, or more, of nodes.

(I'm starting to have visions of vma's having externally visible id's,
in a per-task namespace.)

I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <> 1.650.933.1373, 1.925.600.0401
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.126 / U:8.060 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site