Re: [PATCH 4/5] [RFC][HACK] Add LRU_VOLATILE support to the VM

[Minchan Kim]

Hi John,

On Fri, Jul 27, 2012 at 11:57:11PM -0400, John Stultz wrote:
> In an attempt to push the volatile range managment even
> 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.

I think active list promotion is not good.
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 isvolatile
> 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.

I look at this series and found several nitpicks about implemenataion
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.
So let's talk about it firstly.
I will call VOLATILE list as EReclaimale LRU list.

The purpose of it is that prevent unnecessary LRU churning and
reclaim unnecessary pages fastly so that latency-sensitive system
don't have a big latency when memory pressure happens.

Targets for the LRU list could be following as in future

1. volatile pages in this patchset.
2. ephemeral pages of tmem
3. madivse(DONTNEED)
4. fadvise(NOREUSE)
5. PG_reclaimed pages
6. clean pages if we write CFLRU(clean first LRU)

So if any guys have objection, please raise your hands
before further progress.

> 
> CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> CC: Android Kernel Team <kernel-team@xxxxxxxxxxx>
> CC: Robert Love <rlove@xxxxxxxxxx>
> CC: Mel Gorman <mel@xxxxxxxxx>
> CC: Hugh Dickins <hughd@xxxxxxxxxx>
> CC: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
> CC: Rik van Riel <riel@xxxxxxxxxx>
> CC: Dmitry Adamushko <dmitry.adamushko@xxxxxxxxx>
> CC: Dave Chinner <david@xxxxxxxxxxxxx>
> CC: Neil Brown <neilb@xxxxxxx>
> CC: Andrea Righi <andrea@xxxxxxxxxxxxxxx>
> CC: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
> CC: Mike Hommey <mh@xxxxxxxxxxxx>
> CC: Jan Kara <jack@xxxxxxx>
> CC: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
> CC: Michel Lespinasse <walken@xxxxxxxxxx>
> CC: Minchan Kim <minchan@xxxxxxxxxx>
> CC: linux-mm@xxxxxxxxx <linux-mm@xxxxxxxxx>
> Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>
> ---
>  include/linux/fs.h         |    1 +
>  include/linux/mm_inline.h  |    2 ++
>  include/linux/mmzone.h     |    1 +
>  include/linux/page-flags.h |    3 ++
>  include/linux/swap.h       |    3 ++
>  mm/memcontrol.c            |    1 +
>  mm/page_alloc.c            |    1 +
>  mm/swap.c                  |   71 +++++++++++++++++++++++++++++++++++++++++
>  mm/vmscan.c                |   76 +++++++++++++++++++++++++++++++++++++++++---
>  9 files changed, 155 insertions(+), 4 deletions(-)
> 
-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/