Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Wed, 2 Dec 2020 14:07:37 -0500
From:   TJ <tj@kernel.org>
To:     NeilBrown <neilb@suse.de>
Cc:     Trond Myklebust <trondmy@hammerspace.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFS: switch nfsiod to be an UNBOUND workqueue.
Message-ID: <X8fl+cW4n0wlGkIn@mtj.duckdns.org>
References: <87sg9or794.fsf@notabene.neil.brown.name>
 <37ec02047951a5d61cf9f9f5b4dc7151cd877772.camel@hammerspace.com>
 <87k0uzqqn7.fsf@notabene.neil.brown.name>
 <87pn3zlk8u.fsf@notabene.neil.brown.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87pn3zlk8u.fsf@notabene.neil.brown.name>
Precedence: bulk

On Fri, Nov 27, 2020 at 11:24:33AM +1100, NeilBrown wrote:
> 
> nfsiod is currently a concurrency-managed workqueue (CMWQ).
> This means that workitems scheduled to nfsiod on a given CPU are queued
> behind all other work items queued on any CMWQ on the same CPU.  This
> can introduce unexpected latency.
> 
> Occaionally nfsiod can even cause excessive latency.  If the work item
> to complete a CLOSE request calls the final iput() on an inode, the
> address_space of that inode will be dismantled.  This takes time
> proportional to the number of in-memory pages, which on a large host
> working on large files (e.g..  5TB), can be a large number of pages
> resulting in a noticable number of seconds.
> 
> We can avoid these latency problems by switching nfsiod to WQ_UNBOUND.
> This causes each concurrent work item to gets a dedicated thread which
> can be scheduled to an idle CPU.
> 
> There is precedent for this as several other filesystems use WQ_UNBOUND
> workqueue for handling various async events.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>

Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

-- 
tejun