Re: swap, compress, discard: what's in the future?

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

 



On 01/09/2014 03:18 AM, Bob Liu wrote:

On 01/07/2014 09:45 PM, Rik van Riel wrote:
On 01/07/2014 01:33 AM, Bob Liu wrote:
On Tue, Jan 7, 2014 at 11:01 AM, Minchan Kim <minchan@xxxxxxxxxx> wrote:

Your statement makes sense to me but unfortunately, current VM doesn't
consider everything you mentioned.
It is just based on page access recency by approximate LRU logic +
some heuristic(ex, mapped page and VM_EXEC pages are more precious).

It seems that the ARC page replacement algorithm in zfs have good
performance and more intelligent.
http://en.wikipedia.org/wiki/Adaptive_replacement_cache
Is there any history reason of linux didn't implement something like
ARC as the page cache replacement algorithm?

ARC by itself was quickly superceded by CLOCK-Pro, which
looks like it would be even better.

Johannes introduces an algorithm with similar properties
in his "thrash based page cache replacement" patch series.


But it seems you and Peter have already implemented CLOCK-Pro and CART
page cache replacement many years ago. Why they were not get merged at
that time?

Scalability concerns, lack of time, and the VM not being
ready to take the code.

The split LRU code makes it much more logical to merge a
replacement scheme that is suitable for second level
caches, because the anonymous memory is in an LRU scheme
that is more suitable to its kind of usage.

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




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