xfs
[Top] [All Lists]

Re: [PATCH] [RFC] xfs: lookaside cache for xfs_buf_find

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH] [RFC] xfs: lookaside cache for xfs_buf_find
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 24 Sep 2013 10:48:03 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52404D7F.1080308@xxxxxxx>
References: <1378690396-15792-1-git-send-email-david@xxxxxxxxxxxxx> <52404D7F.1080308@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 23, 2013 at 09:17:35AM -0500, Mark Tinguely wrote:
> On 09/08/13 20:33, Dave Chinner wrote:
> >From: Dave Chinner<dchinner@xxxxxxxxxx>
> >
> >CPU overhead of buffer lookups dominate most metadata intensive
> >workloads. The thing is, most such workloads are hitting a
> >relatively small number of buffers repeatedly, and so caching
> >recently hit buffers is a good idea.
> >
> ...
> 
> I think this needs more testing.

Yes, that's what an "RFC" implies. It's an idea, it's not
fully baked and it's not ready for inclusion - it's a proof of
concept that needs further work, and I't being posted for discussion
to determine if it's worth pursuing further.

Indeed, I haven't proposed it for inclusion yet because I'm
still finding problems caused by the patch - it's still just a
prototype at this point.

> I got the same panic running xfstest 319 with the patch at:
>    http://oss.sgi.com/archives/xfs/2013-09/msg00578.html
> once it hung on a xfs_buf lock before the panic.
> 
> And these are the only tests that I threw at this patch.

Sure. The version I have in my stack at the moment has some more
ixes in it, like handling of length mismatches due to stale buffers
on lookaside lookups, and other such things.

i.e. early feedback on prototype code is exactly what [RFC] patches
are for...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>