Re: Slower performance with lookupcache (2.6.30.2)

[Simon Kirby <sim@hostway.ca>]

On Sat, Jul 25, 2009 at 12:51:43PM -0400, Trond Myklebust wrote:

> On Fri, 2009-07-24 at 16:13 -0700, Simon Kirby wrote:
> > The lookupcache here seems to be increasing initial performance but then
> > seems to slow down cached performance by causing more getattrs than with
> > no lookupcache, perhaps for revalidation tests.
> 
> Yes. This is expected behaviour.
> 
> When you look up a dentry, you are also retrieving its attributes, so
> the stat() call, can be entirely handled by the single LOOKUP rpc call.
> 
> If you are caching the dentries, then your stat() call doesn't need to
> do a lookup, but it still needs to return valid attributes. Since
> acregmin=3 seconds, then your test is likely to have to revalidate a
> couple of times. However as long as there are no changes to the file,
> then the attribute caching algorithm should get progressively more
> aggressive. I'd therefore expect that if you change that to 'repeat 10'
> or so, then the lookupcache=all/positive cases should show an
> improvement.

Ahh, yes, I see, there is.  If I run it longer, I see that it gets even
faster (0.6 seconds) for the forth run and then after a few more, back
up to 4 seconds once.  That makes sense now.

You say that LOOKUP is returning the attributes as well -- is it not
possible to operate the same way doing revalidation?  I was surprised
that there are so many fewer RPC calls during the first run (8622 calls
versus 25076 calls).  But, I suppose it's just readdirplus batching some
information together in a single call (since there are 23,650 files and
directories in the tree), and we probably wouldn't want to readdir all
the time.

Cheers,

Simon-