Hi John,
On Fri, Jul 27, 2012 at 11:57:11PM -0400, John Stultz wrote:In an attempt to push the volatile range managment evenI think active list promotion is not good.
deeper into the VM code, this is my first attempt at
implementing Minchan's idea of a LRU_VOLATILE list in
the mm core.
This list sits along side the LRU_ACTIVE_ANON, _INACTIVE_ANON,
_ACTIVE_FILE, _INACTIVE_FILE and _UNEVICTABLE lru lists.
When a range is marked volatile, the pages in that range
are moved to the LRU_VOLATILE list. Since volatile pages
can be quickly purged, this list is the first list we
shrink when we need to free memory.
When a page is marked non-volatile, it is moved from the
LRU_VOLATILE list to the appropriate LRU_ACTIVE_ list.
It should go to the inactive list and they get a chance to
activate from inactive to active sooner or later if it is
really touched.
This patch introduces the LRU_VOLATILE list, an isvolatileI look at this series and found several nitpicks about implemenataion
page flag, functions to mark and unmark a single page
as volatile, and shrinker functions to purge volatile
pages.
This is a very raw first pass, and is neither performant
or likely bugfree. It works in my trivial testing, but
I've not pushed it very hard yet.
I wanted to send it out just to get some inital thoughts
on the approach and any suggestions should I be going too
far in the wrong direction.
but I think it's not a good stage about concerning it.
Although naming is rather differet with I suggested, I think it's good idea.Yea, I didn't want to call it ERECLAIMABLE since for this iteration I was limiting the scope just to volatile pages. I'm totally fine renaming it as the scope widens.
So let's talk about it firstly.
I will call VOLATILE list as EReclaimale LRU list.