Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9118237pxu; Mon, 28 Dec 2020 07:05:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJzXCxp/HOuQVJOFxeypScEcF1k2jzS7kSnUR5kFfU6Eu1d1JLWYAwm/GbBLhPMPYgQiSw3C X-Received: by 2002:a05:6402:171a:: with SMTP id y26mr43470517edu.371.1609167954497; Mon, 28 Dec 2020 07:05:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609167954; cv=none; d=google.com; s=arc-20160816; b=AKjtYfkH9SJj1IfqKn9lOkHsaiRedO0EJw/liEgkJE467duhbEdKVRDxSEytz2ipw4 b7WLsjJr95frEbMd0t+Ceen/ZqcVPYP1gjNgKxQy3+zLztwzGxhWbbnOWrZRjAn5eFPP 6+pM+iFcuhPXc2hiCrWiPiMN8lYHeAy/Y76wDPtuX8tq6L9U/g4uBgVbDMJSPpCMEfRa wbx8C843eqM+GB1JfA3HTnswkCTRg6BovhkMesncuUvxvEvE1JJjx069shgPqixad8Wf mFa4QrgCkRUaytZJCKFHp7lYds5EmcHXF9ib10y5D6K5PEf/mQqWOcHiVwde0vrubvsl TqGQ== 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=m1BCmMWwpqr/kSqEM1bvQo931ZxBvgK6fc7rUTgyov0=; b=vqARjguG1RnXvTp3HhZ0vwjCZMWCWRk8LrOYfq4LfX9suFQHtVht8JhHEzsmSJksxd yVPEz7BY1q7caUDntwisOZ5lUUOOLTfEKoCgYC2eB3Y5GRHeO/+cPiZ9IcJCaZier9bB PRCrXZp2hOKhoZXB8nqx4RDaCQLhBIfl9jOI16M0LBqYk1BYTbbcNToxuZ9hXqq44vo9 fsj4H2FJHrHDtGWajdfkohJIa1X3Q/8PtJVX0uBPL0L6wr3HfI5fDQwFG9Z5KWsMDYX4 jJEnShue//RCl+cdZSL+a10mpGJ4aAoUB38Wwv+yGE36iMJYnXPYj95QJ/4JsvoHtpK1 xNKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=vsRtaSG5; 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 s16si17015236ejf.641.2020.12.28.07.05.29; Mon, 28 Dec 2020 07:05:54 -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=vsRtaSG5; 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 S2439384AbgL1PD0 (ORCPT + 99 others); Mon, 28 Dec 2020 10:03:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:47334 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2439908AbgL1OMk (ORCPT ); Mon, 28 Dec 2020 09:12:40 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E403B20715; Mon, 28 Dec 2020 14:11:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609164719; bh=c88fvRr+swZWb2kxXqfSCfVxN/ZXmx4v3mzCTZg1Q+U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vsRtaSG5ecx/dcOPHLvY2yV54yxbetL+OUyH+SSMC0QpumuoyTXBbBYQ9f2ypXYj3 0hplEhnTm2fyEoIK/6ZQYKdof18n81ncJLh3e6+AEOB+s89iMEk7S9j3FEzcdw2ooU Sx3HByCK88PKpctGk2VJJkeXtpei6gpMEGQMcxmA= 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 5.10 272/717] NFS: switch nfsiod to be an UNBOUND workqueue. Date: Mon, 28 Dec 2020 13:44:30 +0100 Message-Id: <20201228125034.047066316@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228125020.963311703@linuxfoundation.org> References: <20201228125020.963311703@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 aa6493905bbe8..43af053f467a7 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -2180,7 +2180,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