Messages in this thread | | | Date | Tue, 4 Apr 2006 10:32:41 +0530 | From | "Balbir Singh" <> | Subject | Re: [PATCH] Fix dcache race during umount |
| |
> > * If the dentry is not DCACHED_REFERENCED, it is time to move it to LRU list, > > * provided the super block is NULL (which means we are trying to reclaim memory > > * or this dentry belongs to the same super block that we want to shrink. > > */ > > Ok, thanks. However it isn't time to "move it to the LRU list" but > rather time to "move it from the LRU list, out of the cache all > together, and through it away".
Oops, yes
> > > > > One side-effect of this check I see is > > > > Earlier, all prune_dcache() calls would prune the dentry cache. This > > condition will cause dentries belonging only those super blocks being > > shrink'ed to be freed up. shrink_dcache_memory() will have to do the > > additional work of freeing dentries (especially for file systems like > > sysfs, procfs, etc). But the good thing is it should make the per > > super block operations faster (like unmount). IMO, this is the correct > > behaviour, but I am not sure of the side-effects. > > > > Hmm... yes, but there is a worse side-effect I think. If > shrink_dcache_memory finds a dentry that it cannot free, it will move > it to the head of the LRU, so unmount will not be able to find it so > easily, and will end up moving it back down to the tail. I don't > think this can livelock, but it is unpleasant. > > Rather than move these entries to the head of the list, I'd like to > leave them at the tail, and try to skip over entries that we might not > be able to free.
Yes and you could use the first pass of dcache_shrink_sb() to do that for you.
Thanks, Balbir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |