hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Li Pi ...@idle.li>
Subject Re: LIRS cache as an alternative to LRU cache
Date Tue, 21 Feb 2012 17:14:02 GMT
I thought about this over the summer when I was working on 4027.

Pretty much same idea as Nicholas here. I figured LIRs might be troublesome
to implement - and also thought that newer features, such as 4027 or the
reference counting patch, was a better use of time.

The larger the cache gets, the less the eviction algorithm matters. And we
seem to be trending towards the possibility of larger caches.


On Tue, Feb 21, 2012 at 9:01 AM, Nicolas Spiegelberg <nspiegelberg@fb.com>wrote:

> We had the author of LIRS come to Facebook last year to talk about his
> algorithm and general benefits.  At the time, we were looking at
> increasing block cache efficiency.  The general consensus was that it
> wasn't an exponential perf gain, so we could get bigger wins from
> cache-on-write intelligence, in-memory data compression techniques, and
> adding stats so we could understand how to tune the existing LRU
> algorithm.  I still think that these 3 goals are more important at the
> moment because LIRS would be a decent bit of code and only incremental
> gain.  It's probably something to revisit in a year or two.
> Nicolas
> On 2/21/12 8:26 AM, "yuzhihong@gmail.com" <yuzhihong@gmail.com> wrote:
> >Hi,
> >Shall we experiment with low inter-reference recency set replacement
> >policy to see if block cache becomes more effective ?
> >
> >Cheers
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message