On 09/27/2013 12:20 AM, Luck, Tony wrote:

quoted

And that's it! No other case for page movement. And with this conservative
approach itself, I'm getting great consolidation ratios!
I am also thinking of adding more smartness in the code to be very choosy in
doing the movement, and do it only in cases where it is almost guaranteed to
be beneficial. For example, I can make the kmempowerd kthread more "lazy"
while moving/reclaiming stuff; I can bias the page movements such that "cold"
pages are left around (since they are not expected to be referenced much
anyway) and only the (few) hot pages are moved... etc.

Can (or should) this migrator coordinate with khugepaged - I'd hate to see them
battling over where to move pages ... or undermining each other (your daemon
frees up a 512MB area ... and khugepaged immediately grabs a couple of 2MB
pages from it to upgrade some process with a scattershot of 4K pages).

That's a very good point! I need to look into it to see how such sub-optimal
behavior can be avoided (perhaps by making khugepaged region-aware)... Hmmm..
Thanks for bringing it up!

Regards,
Srivatsa S. Bhat

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