Mailing-List: contact dev-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@trafficserver.apache.org
Received-SPF: pass (nike.apache.org: domain of yunkai.me@gmail.com designates
 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACgLx2qujRTw6wL3s9-hOWUXu7DRs7PBLUV+ZEer-SD41CkJLA@mail.gmail.com>
References: 
 <CAGEauyTFrW4n1PLk40cK5EqgQefnShoH1EHWFL46iafpuNjpbw@mail.gmail.com>
	<CACgLx2o+57Tq5E8Y7oJyTgrCBgx_GUOK4YhXyiUbRbFPw+NFAg@mail.gmail.com>
	<CAGEauyQ2M++nbgigiN3z8LyVmRqidGoMSn9JXq60+G78fqpKjA@mail.gmail.com>
	<CACgLx2qujRTw6wL3s9-hOWUXu7DRs7PBLUV+ZEer-SD41CkJLA@mail.gmail.com>
Date: Sun, 30 Dec 2012 12:50:00 +0800
Message-ID: 
 <CAGEauyR6995Qs+BMLW7nK_cLfSU+m_fGtxjiiPmEgL-XkfYTgA@mail.gmail.com>
Subject: Re: Question about RamCacheLRU
From: Yunkai Zhang <yunkai.me@gmail.com>
To: dev <dev@trafficserver.apache.org>
Content-Type: multipart/alternative; boundary=f46d042f96fc0be1c904d20aa135

--f46d042f96fc0be1c904d20aa135
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 30, 2012 at 12:17 PM, John Plevyak <jplevyak@acm.org> wrote:

> Lol, If they have optimized it by removing the LRU nature, it was perhaps
> overzealous, or perhaps your workload is such that it fits within the RAM
> cache so replacement is not an issue.  Without the LRU there are
> approximately the same number of buckets as objects, so replacement based
> on bucket would be largely random.    Instead we can have a partitioned
> LRU, and we are probably going to have to go that route as it looks like
> lock contention in the cache is pretty bad.  That's the next area I was
> thinking of looking at...
>


It seems that my coworker split the original one LRU queue into multiple
queues according data size(e->data->_size_index). What they do is not to
optimize LRU itself, but to reduce memory fragment caused by allocate/free
memory frequently.

I'll send that patch to here, and hope you can give some advise.


>
> cheers,
> john
>
> On Sat, Dec 29, 2012 at 7:59 PM, Yunkai Zhang <yunkai.me@gmail.com> wrote:
>
> > On Sun, Dec 30, 2012 at 1:57 AM, John Plevyak <jplevyak@acm.org> wrote:
> >
> > > This code in ::put() implements the LRU, and as you can see, it uses
> the
> > > LRU data structure (i.e. simple list from most recently used to least):
> > >
> > >   while (bytes > max_bytes) {
> > >     RamCacheLRUEntry *ee = lru.dequeue();
> > >     if (ee)
> > >       remove(ee);
> > >     else
> > >       break;
> > >   }
> > >
> >
> > It seems that the code I read had been changed on this section you showed
> > above,  as my coworker have optimized it a bit. But thanks for your
> > explanation all the same.
> >
> >
> > >
> > >
> > >
> > > On Sat, Dec 29, 2012 at 9:39 AM, Yunkai Zhang <yunkai.me@gmail.com>
> > wrote:
> > >
> > > > Hi folks:
> > > >
> > > > I'm reading code about RamCacheLRU, but I was confused by
> > > RamCacheLRU->lru
> > > > queue defined as following:
> > > >
> > > > struct RamCacheLRU: public RamCache {
> > > >    ...
> > > >    Que(RamCacheLRUEntry, lru_link) lru;
> > > >    DList(RamCacheLRUEntry, hash_link) *bucket;
> > > >    ...
> > > > };
> > > >
> > > > By reading put/get/remove functions of RamCacheLRU class,  it seems
> > that
> > > > LRU algorithm was implemented by accessing *bucket* list instead of
> > *lru*
> > > > queue.
> > > >
> > > > Do I understand it correctly? if so, we can remove lru queue and
> > relative
> > > > code to speed up the put/get function of LRU a bit.
> > > >
> > > > --
> > > > Yunkai Zhang
> > > > Work at Taobao
> > > >
> > >
> >
> >
> >
> > --
> > Yunkai Zhang
> > Work at Taobao
> >
>


-- 
Yunkai Zhang
Work at Taobao

--f46d042f96fc0be1c904d20aa135--