[Ksummit-2012-discuss] [ATTEND] Easy-Reclaimable LRU list

[Balbir Singh]

On Wed, Jun 20, 2012 at 1:49 PM, Minchan Kim <minchan at kernel.org> wrote:
> Hello,
>
> I would like to attend KS2012.
>
> These days I'm focussed on page allocation/reclaim to reduce latency when the memory pressure happens.
> Recently, there are some efforts to handle system memory pressure.
>
> 1) low memory notification - [1]
> 2) fallocate(VOLATILE) - [2]
> 3) fadvise(NOREUSE) - [3]
>
> For them, I would like to add new LRU list, aka "Ereclaimable" which is opposite of "unevictable".
> Reclaimable LRU list includes _easy_ reclaimable pages.
> For example, easy reclaimable pages are following as.
>
> 1. invalidated but remained LRU list.
> 2. pageout pages for reclaim(PG_reclaim pages)
> 3. fadvise(NOREUSE)
> 4. fallocate(VOLATILE)
>
> Their pages shouldn't stir normal LRU list and compaction might not need migrate them, even.
> Reclaimer can reclaim Ereclaimable pages before normal lru list and will avoid unnecessary
> swapout in anon pages in easy-reclaimable LRU list.
> It also can make admin measure how many we have available pages which are those we can get without big latency
> at the moment.
> It's very important in recent mobile systems because page reclaim/writeback is very critical
> of application latency. Of course, it could affect normal desktop, too.
> With it, we can calculate pages we can get immediately more exactly with NR_FREE_PAGES + NR_ERECLAIMABLE_PAGES,
> for example. If it's below threshold user defined, we might trigger 1st level notification if we really want to prototype low memory notification.
>
> We may change madvise(DONTNEED) implementation instead of zapping page immediately.
> If memory pressure doesn't happen, pages are in memory so we can avoid so many minor fault.
> Of course, we can discard instead of swap out if system memory pressure happens.
> We might implement it madvise(VOLATILE) instead of DONTNEED, but anyway it's off-topic.
>
> As a another example, we can implement CFLRU(Clean-First LRU) which reclaims unmapped-clean cache page firstly.
> The rationale is that in non-rotation device, read/write cost is much asynchronous.
> Read is very fast while write is very slow so it would be a gain while we can avoid writeback of dirty pages
> if possible although we need several reads. It can be implemented easily with Ereclaimable pages, too.
> As a side effect, we can remain dirty pages long time in LRU without pageout and it would be good for
> write bandwidth, too. I guess many mm/fs guys who want to avoid writeback in reclaim path have an interest.
>

Interesting proposal.. I know some of this has been discussed in the
past. Sounds like there are several interesting topics on mm to spawn
it into a separate mini-summit

Balbir