RE: [Results] [RFC PATCH v4 00/40] mm: Memory Power Management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-Tony

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]