Re: [patch 0/5] [PATCH,RFC] vfs: per-superblock unused dentries list (2nd version)

From: Neil Brown
Date: Sun Jun 18 2006 - 20:26:50 EST


On Monday June 19, dgc@xxxxxxx wrote:
>
> > I can see that shrink_dcache_sb could take a long time and should be
> > fixed, which should be as simple as replacing it with
> > shrink_dcache_parent; shrink_dcache_anon.
>
> But these are not guaranteed to reclaim all the dentries from a given
> superblock. Yes, they move the dentries to the LRU, but other activity in the
> system means that they may not get reclaimed during the subsequent calls
> to prune_dcache() and hence they may live beyond the unmount....
>

My proposed patch earlier in this thread (I can post it again if you
like) addresses exactly this issue. Instead of moving dentries to the
global LRU, it moves them to a private LRU, and the calls prune_dcache
on that. So there is no room for other activity to get in the way of
prune_dcache doing what needs to be done.

I agree that using a single big LRU for everything doesn't work. I
just don't think we need (or want) separate LRUs for each superblock.
Rather we want separate temporary LRUs just for use when unmounting.


> > But I'm still puzzled as to why a long dcache LRU slows down
> > unmounting.
> >
> > Can you give more details?
>
> It's not the unmount that slows down - it's the fact that the dcache lock
> is held for so long that rest of the system halts for time it takes
> to run shrink_dcache_sb(). We've seen up to 50s to do a (touch fred; rm fred)
> when the LRU has grown to several million dentries and shrink_dcache_sb()
> is running. When this happens, it's not uncommon to see every CPU in the
> machine spinning on the dcache_lock...

Definitely a problem.
Maybe it was hoped that the call to cond_resched_lock(&dcache_lock)
would avoid this, but apparently not.
I still maintain that we should replace shrink_dcache_sb with calls to
shrink_dcache_anon and shrink_dcache_parent. That, together with my
previous patch, should fix this problem quite cleanly. If I send you
a combined patch against the latest -mm can you test?

Thanks,
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/