From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC][PATCH] nfsd regression since delayed fput() Date: Fri, 25 Oct 2013 15:18:18 +0100 Message-ID: <20131025141818.GD13318@ZenIV.linux.org.uk> References: <20131016185209.GO13318@ZenIV.linux.org.uk> <20131017181457.GA6987@fieldses.org> <20131017183952.GS13318@ZenIV.linux.org.uk> <20131017201207.GT13318@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "J. Bruce Fields" , linux-fsdevel To: Linus Torvalds Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58061 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754899Ab3JYOSV (ORCPT ); Fri, 25 Oct 2013 10:18:21 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Oct 17, 2013 at 03:33:07PM -0700, Linus Torvalds wrote: > On Thu, Oct 17, 2013 at 1:12 PM, Al Viro 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.