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@xxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
