On Monday June 19, [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
