Re: Avoid excessive time spend on concurrent slab shrinking

Nathan Scott
2006-04-01T05:59:42Z

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

> Assuming that there's nothing we can do to improve the XFS situation, our
> options appear to be, in order of preference:
>
> a) move some/all of dispose_list() outside iprune_mutex.
>
> b) make iprune_mutex an rwlock, take it for reading around
> dispose_list(), for writing elsewhere.
>
> c) go back to single-threading shrink_slab (or just shrink_icache_memory())
>
> For this one we'd need to understand which observations prompted Nick
> to make shrinker_rwsem an rwsem?
>
> We also need to understand why this has become worse. Perhaps xfs_iextract
> got slower (cc's Nathan). Do you have any idea whenabout in kernel history
> this started happening?

Nothings changed in xfs_iextract for many years. Its quite possible
the simple hash with linked list buckets is no longer an effective
choice of algorithm here for the inode cluster hash... or perhaps the
hash table is too small... or... but anyway, I would not expect any
difference between kernel versions here (esp. the two vendor kernel
versions Christoph will be comparing - they'll be behaving exactly
the same way in this regard from XFS's POV as the code in question is
identical).

Its also quite possible some other performance bottleneck was moved
out of the way, and lock contention on the chashlist lock is now the
next biggest thing in line..

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

cheers.

--
Nathan