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 E18F7C4332F for ; Thu, 8 Dec 2022 09:00:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D6A38E0003; Thu, 8 Dec 2022 04:00:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7868D8E0001; Thu, 8 Dec 2022 04:00:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64E448E0003; Thu, 8 Dec 2022 04:00:55 -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 574D88E0001 for ; Thu, 8 Dec 2022 04:00:55 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2578CC0F2C for ; Thu, 8 Dec 2022 09:00:55 +0000 (UTC) X-FDA: 80218544070.15.457B305 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by imf19.hostedemail.com (Postfix) with ESMTP id 1FD631A0017 for ; Thu, 8 Dec 2022 09:00:52 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=EzjyjnhE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of almasrymina@google.com designates 209.85.217.53 as permitted sender) smtp.mailfrom=almasrymina@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670490053; 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=/JR2pG9tV9FSrRFa+WDb2jw9B3fBXybAeCMdReMmHEA=; b=YRjCU3tNL5aSlrqG8pJ2MJDLVJTJzl1T66tJB4YJWUR4yEC4IkPJA7XEsr+IWmOYLIMjMG 6hHVh69CDO1kicpq2gqw6ZsI6deCCELg1N0uocj1tSnjLuOnZftn5HFx2k4O8gQGCp3Ycl Gmj352ZFVlZpIwJZLpIqJrVrx+DDuv8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=EzjyjnhE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of almasrymina@google.com designates 209.85.217.53 as permitted sender) smtp.mailfrom=almasrymina@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670490053; a=rsa-sha256; cv=none; b=uS3zWPCx8Nmg3t+Z7f+fkhNAt2qSRM94OVXUeeBOm3Xglty4/Rc66C74tTnS0jksnnS2/8 s4vdwqNQYZCduanyq+g1ervl/h2UuMlQWeXj1gl/zE2zTV39ZPDDoY/mH7kdZh1J9nK8SZ dwap7QrVsgxP9wweU3fZh481+HnlP3k= Received: by mail-vs1-f53.google.com with SMTP id i2so882060vsc.1 for ; Thu, 08 Dec 2022 01:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=/JR2pG9tV9FSrRFa+WDb2jw9B3fBXybAeCMdReMmHEA=; b=EzjyjnhEaXK3XlFKfEJjDH1m9eC1v0n0aiIRocc6iwyNzpxSguqz7Syw2fSRQYYHlE PAUpRLlr+qnUS0aPIFl0oc+rsoV1z6bWBoDe5Z6u9j8osJYs8xRLDBQWPxgEWT7zX6dh KJp0OUQpQ2EIS7H9wajb7F/tL/xECMxIU8fEAniQNmhWbfkkLsU5BzR/DpXVkP1/sn+7 Szdki1JXv2nwz8AOldezpoDfYZb21LXhPOHvf/tGmMrpgR30pm9Dx6wrd+5PQLKBgTUr qcVV3TKhw620Fyp9kf5AbyfFgPy8mA9anJOBqyYiqqrsiuM31or4uoNaAF74GKX4+V6T t3GA== 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=/JR2pG9tV9FSrRFa+WDb2jw9B3fBXybAeCMdReMmHEA=; b=raeodi/2RjHDRsJ3OlBOdWXWXHADbUT+Ywio8+nOQyLgBuwwVRQ4KZJhsxYXRiCtt6 i4CuBLTSYjlHoufv7IzzNMK6shJPUZIUZmXqJCLRb+0rFAAd6y+clTraE5B4rRHmv68x qtEAl+twY1cjvA7YHs0NXr8/yvSAj96jMULbF+haMRSJh7n7yoi5aPgSzKQBnqS4V9Ad 0XqJrdjkASsqxd2q+/9bmalNcK+Z2EdiM5eZwQjG33M+xVbVrZJS8JnoPC0M14TFkHVO c9IYqCyT2kYB3yjs5qbwmeXcDC+YlkMpsFCh93lkGefCt+YftRoK1rSPOISenmSGWe1I nUMA== X-Gm-Message-State: ANoB5pmoOpj7J1y4tafLduNOVFdMzGZ0mn58rN9oL6VpHNlG5pWD202j 3BwHM6cFZGgEpQYHXzI1Oo/tW+bL73Ewzz51qSRjxA== X-Google-Smtp-Source: AA0mqf5IM9NcRNgCI2Fdb5O6N4IdAmRg2deTbxr+Xj6ercC607o7pe9uQk8QDVhskwWn0bUuEFC+Vb/kzRdzuAo2JeY= X-Received: by 2002:a67:ea04:0:b0:3a7:d7bc:c2e9 with SMTP id g4-20020a67ea04000000b003a7d7bcc2e9mr42911158vso.61.1670490051902; Thu, 08 Dec 2022 01:00:51 -0800 (PST) MIME-Version: 1.0 References: <20221206023406.3182800-1-almasrymina@google.com> In-Reply-To: From: Mina Almasry Date: Thu, 8 Dec 2022 01:00:40 -0800 Message-ID: Subject: Re: [PATCH v3] [mm-unstable] mm: Fix memcg reclaim on memory tiered systems To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Huang Ying , Yang Shi , Yosry Ahmed , weixugc@google.com, fvdl@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 1FD631A0017 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 5nsppua5qtehwstimyw5boh7imyqacqc X-HE-Tag: 1670490052-699251 X-HE-Meta: U2FsdGVkX191LfBQNCER8rsgWuIjXNiLFlgoB87xA223Pe2cegkBADAguCwczuUXnlgjv6IZajzLO00j8wA/Th8TuiOFcXBKzH2f0Mhy+FX+FgHSQ1xeIkDdWUDUIvFQUjPtJ44OASMBJs1E+nfdHgHj8Fa6ExG6vE4IB1H7tk5f/oFEvLsJVAzC08Vw86TKu2y45FobV65si7ik0oRZqFrEIpwnqkq9GdA+fFZH0veMdRhPV+iQhSF4id1xs02AkyCjdRfLL+5l4idFmxID+hPJ81cWFcekVpWKCTDhnN3WAn+9RrT76lSPt8UTK6AV9vSm+9B3m8Ds24VGxgh0hrRerkxngAEUnVvLLZYgKDESOnCNwaXNVWj5esOAXYZSc1OobxKnuay5FHL+DFXBln3DBrNjApE1xJYtoQx8zj4+SgBhaRxbhNP86oMT5r5j9SHJ2LHAM59uSCLYOZsyTxYJPSWcpCOGb2kX+FLZ4S7VynLgtOT77AYUCGfvVHnN/i0FsVJ+Oahr424CEXFNMbX7sAS4G3wIeVqzcpBfBxxFetOzmdyjpsaRjnJbhdBD4YRSDUETTsWv/q/lBVVZbdXQi5mHMu8pLCS3EQgU4NAvtqyAI/5XU9rRcPHbvCOTBJ7N99OyeHbvyx3MeGMoB7iPR0FThkRrZk/PIctq5JLQzfh3bRLTS8bLynZ3vk+ZEqPSvkVP8JwQn5KvB2tCkGm2rffDodqh1imzZxXLpOEOhdRHoqxjGwg+R5urk1urDIl5jDYb+qXOpeRwo5OvTbHbaim8h2S1xSehPtjayJsrR0gkfAKd0kZnk9N+2XDo0BLdwnvs/od5/sKvekgRwjrJIuYdrqCS3hhtREVDeaWVCk0CBI5tpImUy2how0+sR4a55bXo9h7T8vNPuVFb2Fr6mtKiHjoPZMu20pBRHjqIgRR4+1GUtwf6/Q2gyenwYnrxCF+g1te9I8ECglJ /tnkNyI0 6/s3yugJHc3w6/u8= 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 8, 2022 at 12:09 AM Michal Hocko wrote: > > On Wed 07-12-22 13:43:55, Mina Almasry wrote: > > On Wed, Dec 7, 2022 at 3:12 AM Michal Hocko wrote: > [...] > > > Anyway a proper nr_reclaimed tracking should be rather straightforward > > > but I do not expect to make a big difference in practice > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > index 026199c047e0..1b7f2d8cb128 100644 > > > --- a/mm/vmscan.c > > > +++ b/mm/vmscan.c > > > @@ -1633,7 +1633,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, > > > LIST_HEAD(ret_folios); > > > LIST_HEAD(free_folios); > > > LIST_HEAD(demote_folios); > > > - unsigned int nr_reclaimed = 0; > > > + unsigned int nr_reclaimed = 0, nr_demoted = 0; > > > unsigned int pgactivate = 0; > > > bool do_demote_pass; > > > struct swap_iocb *plug = NULL; > > > @@ -2065,8 +2065,17 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, > > > } > > > /* 'folio_list' is always empty here */ > > > > > > - /* Migrate folios selected for demotion */ > > > - nr_reclaimed += demote_folio_list(&demote_folios, pgdat); > > > + /* > > > + * Migrate folios selected for demotion. > > > + * Do not consider demoted pages to be reclaimed for the memcg reclaim > > > + * because no charges are really freed during the migration. Global > > > + * reclaim aims at releasing memory from nodes/zones so consider > > > + * demotion to reclaim memory. > > > + */ > > > + nr_demoted += demote_folio_list(&demote_folios, pgdat); > > > + if (!cgroup_reclaim(sc)) > > > + nr_reclaimed += nr_demoted; > > > + > > > /* 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: */ > > > > > > [...] > > > > Thank you again, but this patch breaks the memory.reclaim nodes arg > > for me. This is my test case. I run it on a machine with 2 memory > > tiers. > > > > Memory tier 1= nodes 0-2 > > Memory tier 2= node 3 > > > > mkdir -p /sys/fs/cgroup/unified/test > > cd /sys/fs/cgroup/unified/test > > echo $$ > cgroup.procs > > head -c 500m /dev/random > /tmp/testfile > > echo $$ > /sys/fs/cgroup/unified/cgroup.procs > > echo "1m nodes=0-2" > memory.reclaim > > > > In my opinion the expected behavior is for the kernel to demote 1mb of > > memory from nodes 0-2 to node 3. > > > > Actual behavior on the tip of mm-unstable is as expected. > > > > Actual behavior with your patch cherry-picked to mm-unstable is that > > the kernel demotes all 500mb of memory from nodes 0-2 to node 3, and > > returns -EAGAIN to the user. This may be the correct behavior you're > > intending, but it completely breaks the use case I implemented the > > nodes= arg for and listed on the commit message of that change. > > Yes, strictly speaking the behavior is correct albeit unexpected. You > have told the kernel to _reclaim_ that much memory but demotion are > simply aging handling rather than a reclaim if the demotion target has a > lot of memory free. Yes, by the strict definition of reclaim, you're completely correct. But in reality earlier I proposed a patch to the kernel that disables demotion in proactive reclaim. That would have been a correct change by the strict definition of reclaim, but Johannes informed me that meta already has a dependency on proactive reclaim triggering demotion and directed me to add a nodes= arg to memory.reclaim to trigger demotion instead, to satisfy both use cases. Seems both us and meta are using this interface to trigger both reclaim and demotion, despite the strict definition of the word? > This would be the case without any nodemask as well > btw. > The difference here is that without any nodemask, the kernel will also reclaim from bottom tier nodes, which will count towards the user's request so the behavior makes sense in my opinion. If nodemask=NULL or nodemask=ALL_NODES, then the caller is asking for reclaim across all nodes which should not count demoted pages IMO. The kernel can still look for demotion opportunities, but the demoted pages would not count towards the user's request. > I am worried this will popping up again and again. I thought your nodes > subset approach could deal with this but I have overlooked one important > thing in your patch. The user provided nodemask controls where to > reclaim from but it doesn't constrain demotion targets. Is this > intentional? Would it actually make more sense to control demotion by > addint demotion nodes into the nodemask? > IMO, yes it is intentional, and no I would not recommend adding demotion nodes (I assume you mean adding both demote_from_nodes and demote_to_nodes as arg). My opinion is based on 2 reasons: 1. We control proactive reclaim by looking for nodes/tiers approaching pressure and triggering reclaim/demotion from said nodes/tiers. So we know the node/tier we would like to reclaim from, but not necessarily have a requirement on where the memory should go. I think it should be up to the kernel. 2. Currently I think most tiered machines will have 2 memory tiers, but I think the code is designed to support N memory tiers. What happens if N=3 and the user asks you to demote from the top tier nodes to the bottom tier nodes (skipping the middle tier)? The user in this case is explicitly asking to break the aging pipeline. From my short while on the mailing list I see great interest in respecting the aging pipeline, so it seems to me the demotion target should be decided by the kernel based on the aging pipeline, and the user should not be able to override it? I don't know. Maybe there is a valid use case for that somewhere. > -- > Michal Hocko > SUSE Labs