On Thu, Oct 17, 2013 at 03:33:07PM -0700, Linus Torvalds wrote:

On Thu, Oct 17, 2013 at 1:12 PM, Al Viro [off-list ref] wrote:

quoted

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..

quoted

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.