Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp156952ybx; Thu, 31 Oct 2019 17:49:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqykCHPVlyqEB7qRJdINNy5qLWIz4UjlyS2TQB5IdJR0hxK01hJLGwOZ0nw/IcNMyPGYJxbQ X-Received: by 2002:a50:9fa4:: with SMTP id c33mr9715891edf.176.1572569367324; Thu, 31 Oct 2019 17:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572569367; cv=none; d=google.com; s=arc-20160816; b=JgTpDcLTuqn42W/+vgOIuRVuSTQacNeD0UuFzA40iPADL/1fbowxI/gdO4M5NfAvoi b2evVJ0B6g8ZOiKXaC16OHw5W735VtSsEGjf1D8EzL910QxK461v8nentJgMiVVwASNk Es6ezQt76JqFENQKqKXOhYWUNgt4McnWFqdhUB4w5UiaY/74emG5X81jj0Sruea2TAL+ BvglONJr3TNJNGoG01VJpdodle7zhP5RjN8yrY130dckgESlx7O0aGXoOD0d/G+7M92W xHbv8Bgm+vywtv4Egtshcmmhzb2IQEWY+xTvHWOYEoaNEh3uUwwvt+dQ9TZ4zbTHG5pR E18A== 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=5wKNAcbycOATeGizaaC8yraq+nQ9gtoVsHgY24o+UVY=; b=a7rDf1/iQceAExNd6QlizaD5CD1krzmPzQPSSNDY9BJYy+Vl1Y10FvQezPjiNh+JN3 YAFan1gGz8iyRVEnc4g0+FkS8RadEITpEaymmeqs3dDy69Y//e19xQcyW49uF65jIc61 CV7SsPugYL1uisXGGvHCSKC5WIl1cPPsgo3aUfmYIkjj7QCQo06XvwafsjRTCV6tP61W v6eaSJHu074Btzqjvlo/Bd/BSMc6UyKYu8625oWMgnMxmERUqSfjLVSOzFJhI8xtbD4x 7tovyF8hyPxpyfmduakM9caxS1DB821m4A5YjnVmqyqdIjfqPAECZxdgTwq/CzCRPzLw LLRg== 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 p57si4958085edc.295.2019.10.31.17.48.51; Thu, 31 Oct 2019 17:49:27 -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 S1728074AbfJaXqX (ORCPT + 99 others); Thu, 31 Oct 2019 19:46:23 -0400 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:55323 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727003AbfJaXqX (ORCPT ); Thu, 31 Oct 2019 19:46:23 -0400 Received: from dread.disaster.area (pa49-180-67-183.pa.nsw.optusnet.com.au [49.180.67.183]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 93DF93A0641; Fri, 1 Nov 2019 10:46:21 +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-0007CB-9V; 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-00041Z-7D; 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 09/28] mm: directed shrinker work deferral Date: Fri, 1 Nov 2019 10:45:59 +1100 Message-Id: <20191031234618.15403-10-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=P6RKvmIu c=1 sm=1 tr=0 a=3wLbm4YUAFX2xaPZIabsgw==:117 a=3wLbm4YUAFX2xaPZIabsgw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=MeAgGD-zjQ4A:10 a=20KFwNOVAAAA:8 a=3J8m_CEvPCn7CZIx0tYA:9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Chinner Introduce a mechanism for ->count_objects() to indicate to the shrinker infrastructure that the reclaim context will not allow scanning work to be done and so the work it decides is necessary needs to be deferred. This simplifies the code by separating out the accounting of deferred work from the actual doing of the work, and allows better decisions to be made by the shrinekr control logic on what action it can take. Signed-off-by: Dave Chinner --- include/linux/shrinker.h | 7 +++++++ mm/vmscan.c | 8 ++++++++ 2 files changed, 15 insertions(+) diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h index 0f80123650e2..3405c39ab92c 100644 --- a/include/linux/shrinker.h +++ b/include/linux/shrinker.h @@ -31,6 +31,13 @@ struct shrink_control { /* current memcg being shrunk (for memcg aware shrinkers) */ struct mem_cgroup *memcg; + + /* + * set by ->count_objects if reclaim context prevents reclaim from + * occurring. This allows the shrinker to immediately defer all the + * work and not even attempt to scan the cache. + */ + bool defer_work; }; #define SHRINK_STOP (~0UL) diff --git a/mm/vmscan.c b/mm/vmscan.c index ee4eecc7e1c2..a215d71d9d4b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -536,6 +536,13 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, trace_mm_shrink_slab_start(shrinker, shrinkctl, nr, freeable, delta, total_scan, priority); + /* + * If the shrinker can't run (e.g. due to gfp_mask constraints), then + * defer the work to a context that can scan the cache. + */ + if (shrinkctl->defer_work) + goto done; + /* * Normally, we should not scan less than batch_size objects in one * pass to avoid too frequent shrinker calls, but if the slab has less @@ -570,6 +577,7 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, cond_resched(); } +done: if (next_deferred >= scanned) next_deferred -= scanned; else -- 2.24.0.rc0