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

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

 



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?

I found some information from
http://linux-mm.org/AdvancedPageReplacement

Linux implementations:
Rahul Iyer's implementation of CART, RahulIyerCART

Rik van Riel's ClockProApproximation.

Rik van Riel's proposal for the tracking of NonResidentPages, which is
used by both his ClockProApproximation and by Peter Zijlstra's CART and
Clock-pro implementations.

Peter Zijlstra's CART PeterZCart

Peter Zijlstra's Clock-Pro PeterZClockPro2

Thanks,
-Bob

> However, algorithms like ARC and clockpro are best for
> a cache that caches a large data set (much larger than
> the cache size), and has to deal with large inter-reference
> distances.
> 
> For anonymous memory, we are dealing with the opposite:
> the total amount of anonymous memory is on the same
> order of magnitude as the amount of RAM, and the
> inter-reference distance will be smaller as a result.
> 

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