Re: [RFC][PATCH] nfsd regression since delayed fput()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Oct 17, 2013 at 03:33:07PM -0700, Linus Torvalds wrote:
> On Thu, Oct 17, 2013 at 1:12 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > And we have a tool for dealing with those, if they turn out to be real -
> > flush_delayed_fput(), doing all pending delayed ones.  I would rather
> > avoid using it unless we have a case where it's really needed, though;
> > it can have interesting consequences wrt locking order, etc.
> 
> Fair enough..
> 
> > Frankly, in case of knfsd I'm a lot more concerned about the amount of
> > struct file (all for the same few disk files) sitting around opened and
> > waiting to be closed, just because there's a client saturating a 10G
> > link with read requests...
> 
> I agree that that might be an issue - we've had somewhat similar
> issues with RCU freeing (tons and tons of pending work), although
> quite frankly the RCU grace periods can end up being much longer than
> a jiffy, so I don't know how noticeable it is. But there could be
> latency reasons to try to avoid having *too* much outstanding work,
> so..
> 
> Maybe we should have some (per-cpu) counter, and every N cases we
> should use a zero timeout?

Maybe...  For now, though, I'd rather go for dumb approach and see how
much PITA it leaves - we can always add extra complexity if it turns
out to be a problem.