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 8DD29C4708C for ; Mon, 5 Dec 2022 23:38:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1995A8E0002; Mon, 5 Dec 2022 18:38:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 149338E0001; Mon, 5 Dec 2022 18:38:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 012508E0002; Mon, 5 Dec 2022 18:38:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E83C78E0001 for ; Mon, 5 Dec 2022 18:38:05 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C0DE6120C72 for ; Mon, 5 Dec 2022 23:38:05 +0000 (UTC) X-FDA: 80209868130.15.BB9AF92 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf17.hostedemail.com (Postfix) with ESMTP id 7264440006 for ; Mon, 5 Dec 2022 23:38:05 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fOuWe2ZA; spf=pass (imf17.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670283485; 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=bNLoUhiYobmP9bOtj7/XkDyvOhLAhDsxAU1nXkGHdyM=; b=6s8rvG3f82mPnNnntvaatQvudTVFyK1paW+joQHTv8gm3fXMphCDIBZ0Y7hj1y9s9GOPt0 Kj4e2mZbLom41f++13fGR+UiAGABiimZAtvXs8GQPfofHhU7/9xRYOkcjDLcuOXMr+pj8i K6gmlD8dKoTMkpWvGSgtedhJ5sM8S5g= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fOuWe2ZA; spf=pass (imf17.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670283485; a=rsa-sha256; cv=none; b=jrpE6F664xCdywkPh8kYaC4rH1EOmCvKN4dnl5OuXwJotxHh+tXoi6t7nG+nyx75jF5EF1 lXxPFPYY+mlQyrKv1GCmtZDjI+BggLXaO2ATuL72roVMWydYScM9oVsRo3zjywLABFTW9Y sEuD8EFij7omuVgB7uOf/uKYr9ykA7Y= Received: by mail-pj1-f52.google.com with SMTP id o12so12744922pjo.4 for ; Mon, 05 Dec 2022 15:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bNLoUhiYobmP9bOtj7/XkDyvOhLAhDsxAU1nXkGHdyM=; b=fOuWe2ZA5NZUMq4NUtvsO/z6eY5hOMUUUzgZkRNwMH1XjOT7Hivq9r+UV19vma2M6b F5GjAtwRFsODWgNItqjyucOrnJuh0441y58c96fLfPKwl6iR8efOj/OWoQZzv4NO5rT0 HGGAaZbd+sy+YjZBQV5/CdZIVQOyLhIPmgsJbuhGvn8ZIwD9WIJ0uGYcf/kvPnBwnzG3 HZ59T/MYwza2dFAIe+epjUUyCjKTdIVjnqUE7aH0hwtvE7DrMuH6BpFlJ3YITDlsrGMg 9VLLLhKSelBOsrbMhCUOsVG4kXWaThyNPse2oaY0JoH99et7gAJBPWA7yRepAHyFcGT/ tFKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bNLoUhiYobmP9bOtj7/XkDyvOhLAhDsxAU1nXkGHdyM=; b=cLV00MLW5RCOOIY8/rgBe8RRyXwn2eLGjDccqQ2ZBnAHTqhjSy9izl6MKnZ8Jgf2TU 4pW6/J/WaEgz8K1Jplr5F05jSAVCA5rGaBNsM1mYeide0LghL56T8UlsqLyx1HZC8KTR d8XFDOlyMcpj06n1U6m7W1dsPjmZA3wyjEPNwB+Qkr4hK9rUVed0NqlvtKbdtd+ljC42 QGA/wfvitjYb+fauE7jSZNEDy3n9cXNZ0KRgLS5tucbsZXh/7fedFciw30xF5ITc2/WF kwVEA4ZMrpNZ6xcZ6ssW7JFLB8ArreKdDdh5taxJBGyQAuI59v/dl2gIOfWjaAcpOcAL /sVQ== X-Gm-Message-State: ANoB5pkhIJGnwJZqb1k5bwJo15hHRWnSzmQBgqycPIHiwWXQNwoh1Po8 nAHGWSc+XDzXy46USOPdCFFULr3CwAxn4N7xjt4= X-Google-Smtp-Source: AA0mqf4/T85GnagMf8xKs0oq6Ky1c0Quf5SrKMRVY4uZVBTBFEVHFzGTks3vgUpgKZHnWNzVsgv9lHqGLVkCBEBHfe4= X-Received: by 2002:a17:90a:4889:b0:20d:d531:97cc with SMTP id b9-20020a17090a488900b0020dd53197ccmr93180378pjh.164.1670283484324; Mon, 05 Dec 2022 15:38:04 -0800 (PST) MIME-Version: 1.0 References: <20221201233317.1394958-1-almasrymina@google.com> In-Reply-To: <20221201233317.1394958-1-almasrymina@google.com> From: Yang Shi Date: Mon, 5 Dec 2022 15:37:52 -0800 Message-ID: Subject: Re: [PATCH v1] mm: disable top-tier fallback to reclaim on proactive reclaim To: Mina Almasry Cc: Huang Ying , Yang Shi , Yosry Ahmed , Tim Chen , weixugc@google.com, shakeelb@google.com, gthelen@google.com, fvdl@google.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7264440006 X-Rspam-User: X-Stat-Signature: mfyxfcygi4ujqpt3dcofkop4wyqq8u1r X-Spamd-Result: default: False [1.25 / 9.00]; SORBS_IRL_BL(3.00)[209.85.216.52:from]; BAYES_HAM(-1.85)[86.31%]; BAD_REP_POLICIES(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; RCPT_COUNT_TWELVE(0.00)[12]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[gmail.com:s=20210112]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17:c]; ARC_NA(0.00)[] X-HE-Tag: 1670283485-432764 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 Thu, Dec 1, 2022 at 3:33 PM Mina Almasry wrote: > > Reclaiming directly from top tier nodes breaks the aging pipeline of > memory tiers. If we have a RAM -> CXL -> storage hierarchy, we > should demote from RAM to CXL and from CXL to storage. If we reclaim > a page from RAM, it means we 'demote' it directly from RAM to storage, > bypassing potentially a huge amount of pages colder than it in CXL. > > However disabling reclaim from top tier nodes entirely would cause ooms > in edge scenarios where lower tier memory is unreclaimable for whatever > reason, e.g. memory being mlocked() or too hot to reclaim. In these > cases we would rather the job run with a performance regression rather > than it oom altogether. > > However, we can disable reclaim from top tier nodes for proactive reclaim. > That reclaim is not real memory pressure, and we don't have any cause to > be breaking the aging pipeline. Makes sense to me. Reviewed-by: Yang Shi > > Signed-off-by: Mina Almasry > --- > mm/vmscan.c | 27 ++++++++++++++++++++++++--- > 1 file changed, 24 insertions(+), 3 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 23fc5b523764..6eb130e57920 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2088,10 +2088,31 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, > nr_reclaimed += demote_folio_list(&demote_folios, pgdat); > /* Folios that could not be demoted are still in @demote_folios */ > if (!list_empty(&demote_folios)) { > - /* Folios which weren't demoted go back on @folio_list for retry: */ > + /* > + * Folios which weren't demoted go back on @folio_list. > + */ > list_splice_init(&demote_folios, folio_list); > - do_demote_pass = false; > - goto retry; > + > + /* > + * goto retry to reclaim the undemoted folios in folio_list if > + * desired. > + * > + * Reclaiming directly from top tier nodes is not often desired > + * due to it breaking the LRU ordering: in general memory > + * should be reclaimed from lower tier nodes and demoted from > + * top tier nodes. > + * > + * However, disabling reclaim from top tier nodes entirely > + * would cause ooms in edge scenarios where lower tier memory > + * is unreclaimable for whatever reason, eg memory being > + * mlocked or too hot to reclaim. We can disable reclaim > + * from top tier nodes in proactive reclaim though as that is > + * not real memory pressure. > + */ > + if (!sc->proactive) { > + do_demote_pass = false; > + goto retry; > + } > } > > pgactivate = stat->nr_activate[0] + stat->nr_activate[1]; > -- > 2.39.0.rc0.267.gcb52ba06e7-goog >