On Sat, Apr 14, 2018 at 09:36:23AM -0700, Linus Torvalds wrote: > But it does *not* make sense for the case where we've hit a dentry > that is already on the shrink list. Sure, we'll continue to gather all > the other dentries, but if there is concurrent shrinking, shouldn't we > give up the CPU more eagerly - *particularly* if somebody else is > waiting (it might be the other process that actually gets rid of the > shrinking dentries!)? > > So my gut feel is that we should at least try doing something like > this in select_collect(): > > - if (!list_empty(&data->dispose)) > + if (data->found) > ret = need_resched() ? D_WALK_QUIT : D_WALK_NORETRY; > > because even if we haven't actually been able to shrink something, if > we hit an already shrinking entry we should probably at least not do > the "retry for rename". And if we actually are going to reschedule, we > might as well start from the beginning. > > I realize that *this* thread might not be making any actual progress > (because it didn't find any dentries to shrink), but since it did find > _a_ dentry that is being shrunk, we know the operation itself - on a > bigger scale - is making progress. > > Hmm? That breaks d_invalidate(), unfortunately. Look at the termination conditions in the loop there...
