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?
Linus
--
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
