Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp159818ybx; Thu, 31 Oct 2019 17:52:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqzXbZNk71whBQEgHzt4JP5VqmH6iCDE9VCpbR2+npvcxSajGjoZs4I4JfyONr5qBwdevOwq X-Received: by 2002:a17:906:8288:: with SMTP id h8mr7289665ejx.251.1572569574617; Thu, 31 Oct 2019 17:52:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572569574; cv=none; d=google.com; s=arc-20160816; b=k2hlPDD957+zUpXt7AI7SoI1s/pesqsDRp4ypEtXROIKNVE0blPJpt2Hb9dkpkcYvT UogUaPvfbmFBPmo9zNuVZkTUTFXg4bAeDYk+YqBpzEKoD9mahCN0BGelz9TrHvEp/ODU KgpkhRf6cGNl/uyDbDSly8P3z9VSLqmEB2bcPuqc66+LWK7YKrAQeMmVcHqBvYypa8J9 uE7bSezVJV3s/HJ0pcir6z2YQwhoHLQ6n45v07KzRcf6aywUMK02Pv8iANgJbT8oxiMO VWUIn66uwdopOiyIIOdq0RlrJn4CS4APhurJ9uj9cFfuCuTtih4UedueGcGY2JDOxkOb vcog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=gRAtS1EreBGcgWOWawwzOrhG6tgclw/Pa2yTFeLrVQU=; b=Y1kDTECWXVw1WkOdQ8DOOn5YO1GNRS8ZE/DlEX/lCSZz8ogdofkLMYUcQIrLWPfvFM lL4HBOY0RQdUztymZ8FsQg4Pc5ebbIrD7p7Z3z6smThZqmbV+8uy+F1JeohNWVrBWhOW wjoEWKp8GYS8GWh6DBgoUXEnYYhqWim/zBELabXb3+UrS6VuQWw5qwn321O3HtoAjKgc 7s6BO2cZfgc3J0N7sG7UVFFQiJ+tj7ScfhZUeACsjkQMtbevegezSyjOhSgdN6LdDtpn zWauZ37430ZnaljvshYgCjafCydc8SxhC+O0fAp1dJrbhrQKuO2IpXO1e2zWUzzffzU6 v4Yg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l10si5841448edk.212.2019.10.31.17.52.31; Thu, 31 Oct 2019 17:52:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729587AbfJaXrl (ORCPT + 99 others); Thu, 31 Oct 2019 19:47:41 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:40131 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728696AbfJaXqc (ORCPT ); Thu, 31 Oct 2019 19:46:32 -0400 Received: from dread.disaster.area (pa49-180-67-183.pa.nsw.optusnet.com.au [49.180.67.183]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 61A077EA3C0; Fri, 1 Nov 2019 10:46:26 +1100 (AEDT) Received: from discord.disaster.area ([192.168.253.110]) by dread.disaster.area with esmtp (Exim 4.92.3) (envelope-from ) id 1iQK8x-0007CU-Jz; Fri, 01 Nov 2019 10:46:19 +1100 Received: from dave by discord.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1iQK8x-000421-Hp; Fri, 01 Nov 2019 10:46:19 +1100 From: Dave Chinner To: linux-xfs@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 18/28] xfs: don't block kswapd in inode reclaim Date: Fri, 1 Nov 2019 10:46:08 +1100 Message-Id: <20191031234618.15403-19-david@fromorbit.com> X-Mailer: git-send-email 2.24.0.rc0 In-Reply-To: <20191031234618.15403-1-david@fromorbit.com> References: <20191031234618.15403-1-david@fromorbit.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=D+Q3ErZj c=1 sm=1 tr=0 a=3wLbm4YUAFX2xaPZIabsgw==:117 a=3wLbm4YUAFX2xaPZIabsgw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=MeAgGD-zjQ4A:10 a=20KFwNOVAAAA:8 a=x2yLRZ3W9cWBXR4-ZBgA:9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Chinner We have a number of reasons for blocking kswapd in XFS inode reclaim, mainly all to do with the fact that memory reclaim has no feedback mechanisms to throttle on dirty slab objects that need IO to reclaim. As a result, we currently throttle inode reclaim by issuing IO in the reclaim context. The unfortunate side effect of this is that it can cause long tail latencies in reclaim and for some workloads this can be a problem. Now that the shrinkers finally have a method of telling kswapd to back off, we can start the process of making inode reclaim in XFS non-blocking. The first thing we need to do is not block kswapd, but so that doesn't cause immediate serious problems, make sure inode writeback is always underway when kswapd is running. As we don't block kswapd now, we don't have to worry about reclaim scans taking long delays due to IO being issued and waited for. Hence while direct reclaim gets delayed by IO, kswapd will not and so it will keep pushing the AIL to clean inodes. Hence direct reclaim doesn't need to push the AIL anymore as kswapd will do it reliably now. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster --- fs/xfs/xfs_icache.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index 944add5ff8e0..edcc3f6bb3bf 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -1378,11 +1378,22 @@ xfs_reclaim_inodes_nr( struct xfs_mount *mp, int nr_to_scan) { - /* kick background reclaimer and push the AIL */ + int sync_mode = SYNC_TRYLOCK; + + /* kick background reclaimer */ xfs_reclaim_work_queue(mp); - xfs_ail_push_all(mp->m_ail); - return xfs_reclaim_inodes_ag(mp, SYNC_TRYLOCK | SYNC_WAIT, &nr_to_scan); + /* + * For kswapd, we kick background inode writeback. For direct + * reclaim, we issue and wait on inode writeback to throttle + * reclaim rates and avoid shouty OOM-death. + */ + if (current_is_kswapd()) + xfs_ail_push_all(mp->m_ail); + else + sync_mode |= SYNC_WAIT; + + return xfs_reclaim_inodes_ag(mp, sync_mode, &nr_to_scan); } /* -- 2.24.0.rc0