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.

~Li

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

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