On Wed, 8 Feb 2006 04:06 pm, Con Kolivas wrote:

On Wed, 8 Feb 2006 03:46 pm, Paul Jackson wrote:

quoted

Con, responding to Nick:

quoted

quoted

It introduces global cacheline bouncing in pagecache allocation and
removal and page reclaim paths, also low watermark failure is quite
common in normal operation, so that is another global cacheline write
in page allocation path.

None of these issues is going to remotely the target audience. If the
issue is how scalable such a change can be then I cannot advocate
making the code smart and complex enough to be numa and cpuset aware..
but then that's never going to be the target audience. It affects a
particular class of user which happens to be quite a large population
not affected by complex memory hardware.

How about only moving memory back to the Memory Node (zone) that it
came from?  And providing some call that Christoph Lameters migration
code can call, to disable or fix this up, so you don't end up bringing
back pages on their pre-migration nodes?

Sounds good, and this is what I was hoping to be able to do; first I need
to see the best time and place to get this information (and learn some more
about the code).

Actually it's looking an awful lot like I should just use one thread per pgdat 
and have per node data. Given that, I should probably just make this a task 
for kswapd since that is what they already are - and the name isn't wrong 
either.

Cheers,
Con

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