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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
