Re: Avoid excessive time spend on concurrent slab shrinking

David Chinner
2006-04-01T18:30:38Z

On Sat, Apr 01, 2006 at 03:59:42PM +1000, Nathan Scott wrote:
> On Fri, Mar 31, 2006 at 05:25:18PM -0800, Andrew Morton wrote:
> > Christoph Lameter <clameter@sgi.com> wrote:
> > ...
> > It appears that we're being busy in xfs_iextract(), but it would be sad if
> > the problem was really lock contention in xfs_iextract(), and we just
> > happened to catch it when it was running.
> >
> > Or maybe xfs_iextract is just slow. So this is one thing we need to get to
> > the bottom of (profiles might tell us).
>
> I assume (profiles would be good to prove it) we are spending
> time walking the hash bucket list there Christoph (while we're
> holding the ch_lock spinlock on the hash bucket)? [CC'ing Dave
> Chinner for any further comment, he's been looking at the chash
> list for unrelated reasons recently..]

You'll only get contention if something else is trying to walk the
same hash chain, which tends to implicate not enough hash buckets.

> If its useful for experimenting, Christoph, you can easily tweak the
> cluster hash size manually by dinking with xfs_iget.c::xfs_chash_init.

Just use the ihashsize mount option - the cluster hash size is proportional
to the inode hash size which is changed by the ihashsize mount option.

Cheers,

Dave.
--
Dave Chinner
R&D Software Enginner
SGI Australian Software Group