Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9172921pxu; Mon, 28 Dec 2020 08:23:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJxTZFs7WAUPvgjWVn1BAXsgkh2K+Duz3fT4CaNNixw2SQqAqpx+80DDtTEm8VmLBOlc6hKb X-Received: by 2002:a17:907:9614:: with SMTP id gb20mr30559854ejc.406.1609172590628; Mon, 28 Dec 2020 08:23:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609172590; cv=none; d=google.com; s=arc-20160816; b=OR2kjg+krXhvtsH16JAVffNXwWBrtOlEkluYgb+BcU9Mb41pgSIr/fa0Iuc+vJnKx8 8P8VNEfe1YwfX1XdptVTa/D7xGA8VUXZ5/glBHeG+fyiejn6fYwLFKWyqa91yZwcJEGb ZtwBiNups0OTZLegSZEN4iGK6AKD3AuSKuLjKFB24XQS2o6ak+2im2pkoIf0eoZQemX1 3MsO3DCYiQ5uFVEs3/tI98GKu227Jo4y+/WouqkNgxcW9NFawLNaPq6qmfF4tokMhDFG gWOzqdIcwHtGBC57Whe4gyLata1peMXiU5T0bx1X6blhdZe12Jr+WcV4fh0AgyMsGH6a mHCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=DMfkhg9tj8Mk8lE9VWdycTpKg5RbksdchVxWoSsG2eA=; b=GIs0Ozre/OtLCc8LhDthS6ixMnuqALxQjJdvVqnn0rkzAA8lOdSiyKAPQRGlnnCM3q YzZ1qpcHLc+3MkjqcGUVy3h01iW4iZR2kxAC3RH8YnI5HCi06MrrMFCy/cPiDlJKlkBQ hCc88fY/V2m9dGmUwy+nlnZbBvx7E5HDLhfIa6GskhN/y2ZrZqzHp911awRlM3m4aMHB GmDGXkfFoNk4rdZe1/woe5xZUP26lmgm11WCJnr3KaoKGlM54HHCehdI41j3VyKZNNoK NjfTlU1Q4Q++M7JhHLZYaT/CPu91vJDqeyzF1Fzuy+v4jhPnvErOqsEhV4pjsKrJ807s Y7aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vYyXNR50; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si20954246edz.485.2020.12.28.08.22.48; Mon, 28 Dec 2020 08:23:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vYyXNR50; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732289AbgL1NNo (ORCPT + 99 others); Mon, 28 Dec 2020 08:13:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:41792 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732263AbgL1NNi (ORCPT ); Mon, 28 Dec 2020 08:13:38 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id EB041207CF; Mon, 28 Dec 2020 13:12:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609161177; bh=NjVV+9KOdz4eRl+QE0xrsLLpG973f98FJxbwA9QoqPQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vYyXNR504u4m1RYLSZAVFHLGyuGtoCpyi2Ji0hH5+UDgtsw7UhR76PfpKs58CHzf6 ODtgsmm8d4csGeAyiMpUa4ACOQ8ithYvcAyZU7qXU7bzpo8rdyL8pxqn815rdi/KST 7VkZiL2/aVbflpA9ObNhPnIBVc9Ank0Iqgn3eMhk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, NeilBrown , Trond Myklebust , Sasha Levin Subject: [PATCH 4.14 127/242] NFS: switch nfsiod to be an UNBOUND workqueue. Date: Mon, 28 Dec 2020 13:48:52 +0100 Message-Id: <20201228124910.950363440@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228124904.654293249@linuxfoundation.org> References: <20201228124904.654293249@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: NeilBrown [ Upstream commit bf701b765eaa82dd164d65edc5747ec7288bb5c3 ] 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 Fixes: ada609ee2ac2 ("workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin --- fs/nfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index 71a399f6805ac..f0534b356f071 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -2053,7 +2053,7 @@ static int nfsiod_start(void) { struct workqueue_struct *wq; dprintk("RPC: creating workqueue nfsiod\n"); - wq = alloc_workqueue("nfsiod", WQ_MEM_RECLAIM, 0); + wq = alloc_workqueue("nfsiod", WQ_MEM_RECLAIM | WQ_UNBOUND, 0); if (wq == NULL) return -ENOMEM; nfsiod_workqueue = wq; -- 2.27.0