Peter Chubb wrote:

A possibly stupid suggestion: 

Can page migration be done lazily, instead of all at once?  Move the
process, mark its pages as candidates for migration, and when 
the page faults, decide whether to copy across or not...

That way you only copy the pages the process is using, and only copy
each page once.  It makes copy for replication easier in some future
incarnation, too, because the same basic infrastructure can be used.

I think that part of the motivation here (e. g. the batch scheduler on
a  large NUMA machine) is to push pages off of the old nodes so that
a new job running on the old nodes can allocate memory quickly and
efficiently (i. e. without having to swap out the old job's pages).

True enough, we may move pages that are not currently being used.
But. on our large NUMA systems, we want the nodes where a new job
starts to be relatively clean so that local page allocations are
indeed satisfied by local pages and that these requests do not
spill off node.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

-- 
-----------------------------------------------
Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@sgi.com             raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
	 so I installed Linux.
-----------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>