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 0661EC00140 for ; Mon, 8 Aug 2022 14:07:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58EA68E0001; Mon, 8 Aug 2022 10:07:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53E0F6B0072; Mon, 8 Aug 2022 10:07:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DE218E0001; Mon, 8 Aug 2022 10:07:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2FC576B0071 for ; Mon, 8 Aug 2022 10:07:41 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EBBD71A01AF for ; Mon, 8 Aug 2022 14:07:40 +0000 (UTC) X-FDA: 79776603480.14.F076CA2 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf31.hostedemail.com (Postfix) with ESMTP id 3EE842015B for ; Mon, 8 Aug 2022 14:07:40 +0000 (UTC) Received: by mail-wr1-f42.google.com with SMTP id l22so11042085wrz.7 for ; Mon, 08 Aug 2022 07:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8uj4c1kjurHbYX6/YjiMD1Fb+tFC84nmGWjnRASCB5M=; b=IFumVuj4KgRc2VjcqRUmBZdn9ZFwr4Xb5El7OQuHLcycXIdwKKj/Pb4vclzOtUgILY EgDcg8axeRvvv4cIEmo23p7SNXvrvUCTFElQfFL+T9IQKiLgJQOLweFdKxE9lz/Ofluw XFL+86u3EgSQj+RQfBYdWWsqAWrGXechIKAWqInLjZr568pPwarcHGbPty72mlzXG26B psVia66zGA+GaMN5r5N70HTCo5qRf+4nHrlaupCMqBC2CeRUx7Xw1BPQCxQQQ6fCi8QQ fLxTmMtpzeM7V//80CRqaP0jeBcU+2kkjU89uYWymt9znmAvs7DJbwlEwRiWLSCyyKKy fBUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8uj4c1kjurHbYX6/YjiMD1Fb+tFC84nmGWjnRASCB5M=; b=qGHcpsq08y8VFV+BubF+dJc61rNtzgwRQ409jnRiD6704xO/zdc0Gq1uapfi07nIf/ FCIguAU8bcNJ0JP4YhkO/u8mKcT5bZikEFVBrB70aqEODZLTuv3AskV9P3ept7/gNe7o 3bdGtG/tkh8RlTgse6khC+Q9YNW/zonJp0JJpam2A63dQwXxTdjox2MmdyrqBIgRlgHh TpaLjKqLYe3gtYUwlROXPxxB4iKih5LSG4dkf2b0XfnSBkV4MCXh6G/FLLI/tS9T9Icz RPqzg+I3qWw7wW3XzkSc9ml20oGqdnL7YyU6rfrXy/XK6w2t0UPwSXr6+t8hZU+ZcPv6 ui0w== X-Gm-Message-State: ACgBeo2MyzdFVWSVzjdJ6wj4luzWYgWxBqA2hWeFqTk7aOH8+a1r4aTm IWjc9OJnpZSZxC4gg6k4CNfxtMpNYLp+RYczgJ8upQ== X-Google-Smtp-Source: AA6agR7qHSjoWclSIH2OF+FbjF9AiI4tjVrnrPviRYKn0a3fWScTIOdMZ4ixk/uJ+A3X02dELe2nvI+WyEJ06uersyU= X-Received: by 2002:a5d:5a82:0:b0:21e:2899:60bd with SMTP id bp2-20020a5d5a82000000b0021e289960bdmr11117769wrb.80.1659967658759; Mon, 08 Aug 2022 07:07:38 -0700 (PDT) MIME-Version: 1.0 References: <20220802162811.39216-1-hannes@cmpxchg.org> In-Reply-To: From: Yosry Ahmed Date: Mon, 8 Aug 2022 07:07:02 -0700 Message-ID: Subject: Re: [PATCH] mm: vmscan: fix extreme overreclaim and swap floods To: Johannes Weiner Cc: Andrew Morton , Mel Gorman , Hugh Dickins , Joonsoo Kim , Linux-MM , Linux Kernel Mailing List , Kernel Team Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659967660; a=rsa-sha256; cv=none; b=T+7BfDyRJVlxSgk0FNKU6hU4Qj0EzqHijFAWBmCwwDXDKoDbY+mbJNEv1LonPN42ahOCNR RJIc6REyit/kTSp80mFAxvsdj/V9pcEr0TFRnPjwQsrtorM4cdaUa+1dzTUwqhm8+CS02D IvIVyk0TyuQH3l+W2l8wNgb85GNRKZs= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=IFumVuj4; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf31.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659967660; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8uj4c1kjurHbYX6/YjiMD1Fb+tFC84nmGWjnRASCB5M=; b=vNZeX0u2nHVvs44TIpDxtjUZTdWcroxuBrEV0MqT1vxddA+jGhxC8JXzv1MFtjBDwDxbO2 PQOBzSH14uEKN9q5shmbgWACRMNMfrFzNU8ZJ4hUY+7QjScdsuSyBUDImlR8x1gKT0V3/o kpLz3I2eeW6Cd6kjVRCDiBGwZQUzYwk= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3EE842015B Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=IFumVuj4; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf31.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspam-User: X-Stat-Signature: nbao89ro9f4qrp1spnqndyd1c4gfjstm X-HE-Tag: 1659967660-639924 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 Mon, Aug 8, 2022 at 6:54 AM Yosry Ahmed wrote: > > On Tue, Aug 2, 2022 at 9:28 AM Johannes Weiner wrote: > > > > During proactive reclaim, we sometimes observe severe overreclaim, > > with several thousand times more pages reclaimed than requested. > > > > This trace was obtained from shrink_lruvec() during such an instance: > > > > prio:0 anon_cost:1141521 file_cost:7767 > > nr_reclaimed:4387406 nr_to_reclaim:1047 (or_factor:4190) > > nr=[7161123 345 578 1111] > > > > While he reclaimer requested 4M, vmscan reclaimed close to 16G, most > > of it by swapping. These requests take over a minute, during which the > > write() to memory.reclaim is unkillably stuck inside the kernel. > > > > Digging into the source, this is caused by the proportional reclaim > > bailout logic. This code tries to resolve a fundamental conflict: to > > reclaim roughly what was requested, while also aging all LRUs fairly > > and in accordance to their size, swappiness, refault rates etc. The > > way it attempts fairness is that once the reclaim goal has been > > reached, it stops scanning the LRUs with the smaller remaining scan > > targets, and adjusts the remainder of the bigger LRUs according to how > > much of the smaller LRUs was scanned. It then finishes scanning that > > remainder regardless of the reclaim goal. > > > > This works fine if priority levels are low and the LRU lists are > > comparable in size. However, in this instance, the cgroup that is > > targeted by proactive reclaim has almost no files left - they've > > already been squeezed out by proactive reclaim earlier - and the > > remaining anon pages are hot. Anon rotations cause the priority level > > to drop to 0, which results in reclaim targeting all of anon (a lot) > > and all of file (almost nothing). By the time reclaim decides to bail, > > it has scanned most or all of the file target, and therefor must also > > scan most or all of the enormous anon target. This target is thousands > > of times larger than the reclaim goal, thus causing the overreclaim. > > > > The bailout code hasn't changed in years, why is this failing now? > > The most likely explanations are two other recent changes in anon > > reclaim: > > > > 1. Before the series starting with commit 5df741963d52 ("mm: fix LRU > > balancing effect of new transparent huge pages"), the VM was > > overall relatively reluctant to swap at all, even if swap was > > configured. This means the LRU balancing code didn't come into play > > as often as it does now, and mostly in high pressure situations > > where pronounced swap activity wouldn't be as surprising. > > > > 2. For historic reasons, shrink_lruvec() loops on the scan targets of > > all LRU lists except the active anon one, meaning it would bail if > > the only remaining pages to scan were active anon - even if there > > were a lot of them. > > > > Before the series starting with commit ccc5dc67340c ("mm/vmscan: > > make active/inactive ratio as 1:1 for anon lru"), most anon pages > > would live on the active LRU; the inactive one would contain only a > > handful of preselected reclaim candidates. After the series, anon > > gets aged similarly to file, and the inactive list is the default > > for new anon pages as well, making it often the much bigger list. > > > > As a result, the VM is now more likely to actually finish large > > anon targets than before. > > > > Change the code such that only one SWAP_CLUSTER_MAX-sized nudge toward > > the larger LRU lists is made before bailing out on a met reclaim goal. > > > > This fixes the extreme overreclaim problem. > > > > Fairness is more subtle and harder to evaluate. No obvious misbehavior > > was observed on the test workload, in any case. Conceptually, fairness > > should primarily be a cumulative effect from regular, lower priority > > scans. Once the VM is in trouble and needs to escalate scan targets to > > make forward progress, fairness needs to take a backseat. This is also > > acknowledged by the myriad exceptions in get_scan_count(). This patch > > makes fairness decrease gradually, as it keeps fairness work static > > over increasing priority levels with growing scan targets. This should > > make more sense - although we may have to re-visit the exact values. > > > > Signed-off-by: Johannes Weiner > > --- > > mm/vmscan.c | 10 ++++------ > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index f7d9a683e3a7..1cc0c6666787 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2897,8 +2897,8 @@ static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > > enum lru_list lru; > > unsigned long nr_reclaimed = 0; > > unsigned long nr_to_reclaim = sc->nr_to_reclaim; > > + bool proportional_reclaim; > > struct blk_plug plug; > > - bool scan_adjusted; > > > > get_scan_count(lruvec, sc, nr); > > > > @@ -2916,8 +2916,8 @@ static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > > * abort proportional reclaim if either the file or anon lru has already > > * dropped to zero at the first pass. > > */ > > - scan_adjusted = (!cgroup_reclaim(sc) && !current_is_kswapd() && > > - sc->priority == DEF_PRIORITY); > > + proportional_reclaim = (!cgroup_reclaim(sc) && !current_is_kswapd() && > > + sc->priority == DEF_PRIORITY); > > > > blk_start_plug(&plug); > > while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] || > > @@ -2937,7 +2937,7 @@ static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > > > > cond_resched(); > > > > - if (nr_reclaimed < nr_to_reclaim || scan_adjusted) > > + if (nr_reclaimed < nr_to_reclaim || proportional_reclaim) > > continue; > > > > /* > > @@ -2988,8 +2988,6 @@ static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > > nr_scanned = targets[lru] - nr[lru]; > > nr[lru] = targets[lru] * (100 - percentage) / 100; > > nr[lru] -= min(nr[lru], nr_scanned); > > - > > - scan_adjusted = true; > > Thanks for the great analysis of the problem! > > I have a question here. This fixes the overreclaim problem for > proactive reclaim (and most other scenarios), but what about the case > where proportional_reclaim (aka scan_adjusted) is set before we start > shrinking lrus: global direct reclaim on DEF_PRIORITY? If we hit a > memcg that has very few file pages and a ton of anon pages in this > scenario (or vice versa), wouldn't we still overreclaim and possibly > stall unnecessarily? or am I missing something here? Never mind :) In this scenario we will keep iterating the LRUs anyway, we don't attempt to make the scanning proportional. I guess the new name (proportional_reclaim) confused me :) > > > } > > blk_finish_plug(&plug); > > sc->nr_reclaimed += nr_reclaimed; > > -- > > 2.37.1 > > > >