From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C50EFC433EF for ; Wed, 24 Nov 2021 11:50:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF3416B0075; Wed, 24 Nov 2021 06:50:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA2DF6B0078; Wed, 24 Nov 2021 06:50:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D92296B007B; Wed, 24 Nov 2021 06:50:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id CA3A86B0075 for ; Wed, 24 Nov 2021 06:50:21 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 75F231849B232 for ; Wed, 24 Nov 2021 11:50:11 +0000 (UTC) X-FDA: 78843655422.06.2D8DE44 Received: from outbound-smtp24.blacknight.com (outbound-smtp24.blacknight.com [81.17.249.192]) by imf09.hostedemail.com (Postfix) with ESMTP id 4559F300012C for ; Wed, 24 Nov 2021 11:50:07 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp24.blacknight.com (Postfix) with ESMTPS id 40D06C0E5E for ; Wed, 24 Nov 2021 11:50:09 +0000 (GMT) Received: (qmail 1218 invoked from network); 24 Nov 2021 11:50:09 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.29]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 24 Nov 2021 11:50:09 -0000 Date: Wed, 24 Nov 2021 11:50:07 +0000 From: Mel Gorman To: Alexey Avramov Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.com, vbabka@suse.cz, neilb@suse.de, akpm@linux-foundation.org, corbet@lwn.net, riel@surriel.com, hannes@cmpxchg.org, david@fromorbit.com, willy@infradead.org, hdanton@sina.com, penguin-kernel@i-love.sakura.ne.jp, oleksandr@natalenko.name, kernel@xanmod.org, michael@michaellarabel.com, aros@gmx.com, hakavlad@gmail.com Subject: Re: mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions Message-ID: <20211124115007.GG3366@techsingularity.net> References: <20211124011954.7cab9bb4@mail.inbox.lv> <20211124103550.GE3366@techsingularity.net> <20211124195449.33f31e7f@mail.inbox.lv> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20211124195449.33f31e7f@mail.inbox.lv> User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: z456co4kpthnfeqmj4ifo8q6mmdu91ag X-Rspamd-Queue-Id: 4559F300012C X-Rspamd-Server: rspam07 Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.192 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none X-HE-Tag: 1637754607-544481 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 24, 2021 at 07:54:49PM +0900, Alexey Avramov wrote: > > it does eventually get killed OOM > > However, a full minute freeze can be a great evil in many situations - > during such a freeze, the system is completely unresponsive. > > So my next question is: How reasonable is the value MAX_RECLAIM_RETRIES? > Is it also get "out of thin air"? > The value is out of thin air but adjusting it may reintroduce issues with kswapd running at 100% CPU. > And would it make sense to have buttons to adjust the timeouts? I don't think we should introduce a tunable for something like this, it'll be impossible to use properly but can you test this? diff --git a/mm/vmscan.c b/mm/vmscan.c index 07db03883062..aa72c0f39dcc 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1058,6 +1058,14 @@ void reclaim_throttle(pg_data_t *pgdat, enum vmscan_throttle_state reason) break; case VMSCAN_THROTTLE_NOPROGRESS: timeout = HZ/2; + + /* + * If kswapd is disabled, use the minimum timeout as the + * system may be at or near OOM. + */ + if (pgdat->kswapd_failures >= MAX_RECLAIM_RETRIES) + timeout = 1; + break; case VMSCAN_THROTTLE_ISOLATED: timeout = HZ/50; @@ -3395,7 +3403,7 @@ static void consider_reclaim_throttle(pg_data_t *pgdat, struct scan_control *sc) return; /* Throttle if making no progress at high prioities. */ - if (sc->priority < DEF_PRIORITY - 2) + if (sc->priority < DEF_PRIORITY - 2 && !sc->nr_reclaimed) reclaim_throttle(pgdat, VMSCAN_THROTTLE_NOPROGRESS); } @@ -3415,6 +3423,7 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) unsigned long nr_soft_scanned; gfp_t orig_mask; pg_data_t *last_pgdat = NULL; + pg_data_t *first_pgdat = NULL; /* * If the number of buffer_heads in the machine exceeds the maximum @@ -3478,14 +3487,18 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc) /* need some check for avoid more shrink_zone() */ } + if (!first_pgdat) + first_pgdat = zone->zone_pgdat; + /* See comment about same check for global reclaim above */ if (zone->zone_pgdat == last_pgdat) continue; last_pgdat = zone->zone_pgdat; shrink_node(zone->zone_pgdat, sc); - consider_reclaim_throttle(zone->zone_pgdat, sc); } + consider_reclaim_throttle(first_pgdat, sc); + /* * Restore to original mask to avoid the impact on the caller if we * promoted it to __GFP_HIGHMEM.