On 09/27/2013 12:20 AM, Luck, Tony wrote: >> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>