Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp9179838pxu; Mon, 28 Dec 2020 08:33:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJyO6oR62LiV+b5EyGVnmEdSva0FHp7nZlsvW298KdS2SCoinmv7xgMXIPyVJ3UGm96KlQST X-Received: by 2002:a17:906:705:: with SMTP id y5mr40873918ejb.428.1609173228431; Mon, 28 Dec 2020 08:33:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609173228; cv=none; d=google.com; s=arc-20160816; b=rbxg28EL4zkTrctrFjCdjviPikEKjc1yUnO4Iqm8NOy5/jkXJ+IZuqvgj7OUS0TKBN HpeDUiK/qnBXYSn9U7cnhW0NO1ZQ4eEgumIpS6cjs0E1RjZLbyFIACNRKfwW3l5FcykI dOfO/F0tlnIW8mf6Tf965+C2gOpbvjv9apwkx+1sQFGn5aVxQ/IeG4jtqqMrHDc3VBUR z/OqVZ7oSTG0Lxt8oztZObMuCGZFHmhbfxMHZa+rW3IzJXRhfxMrCa0e0hq0teiPa/SN wXVZEG7R4YoMki/FKoW+LsSRVgqdwYTJfY726YBC7D1fQQhC0d7LIYxFor8rMvc+Ur9p d1rw== 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=HiacvGhzb2/bS+8/slDXd1I2KuAP7LuHi+YrExuIZZQ=; b=nWUjhd4Js5mECLMUmbxbWBas2vyFJc3zs6vHsDN7hELQyYKylO5nZUd88GHAfhjSKK jfUPbiyS7m0ER1qYpUg6dRtCCrJPR5BZ9ZMdfu4aKbS7+2YBHn2VW0r8OxRgFhqXUWx9 c+z3oCcIQHe4L+hVPfkR98qU0ytoWG8rmc7hp4bAh9yUkjfJuwxVNv8q4sREuz9gnUCw V2Ro2+dZ5yGBSXgre3IZThROBitq4z2JChfB9YX3q3U7PZ1uKjOrtC9ccYsimI3mgfnz wfvXtTkuq2MqIgkDyPgUUwczqGlRZddUO1RmbghB+vebtzSSAH1rn1q0OyHZ5MyHdKSI 7LbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DuTukr2U; 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 gu26si18158952ejb.461.2020.12.28.08.33.25; Mon, 28 Dec 2020 08:33:48 -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=DuTukr2U; 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 S2441871AbgL1Qbv (ORCPT + 99 others); Mon, 28 Dec 2020 11:31:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:60790 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730489AbgL1NEj (ORCPT ); Mon, 28 Dec 2020 08:04:39 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6B44322582; Mon, 28 Dec 2020 13:03:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609160639; bh=dk4t7gfGTMw5YQaATINpxtv/8lOtwfdQJeyfNPjtTl4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DuTukr2UQrqgDZn8lobX1S0U1J4vMTsN1VSj/XqIzfkvoIZpZZ6glTIQeL1LTDLs9 Cb3eqGyl8CTjM8zlZ4m02BCZmvuIkKtCnIC+6iovxH3xeIk6B/Z+2rP2NnUt6obuZq Zr5COOFVFHGKgeQhIWV4WIuovFaSAPg6a9sxEp2g= 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.9 089/175] NFS: switch nfsiod to be an UNBOUND workqueue. Date: Mon, 28 Dec 2020 13:49:02 +0100 Message-Id: <20201228124857.561327172@linuxfoundation.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20201228124853.216621466@linuxfoundation.org> References: <20201228124853.216621466@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 851274b25d394..6c0035761d170 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -1995,7 +1995,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