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 46063C4332F for ; Fri, 2 Dec 2022 03:15:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C720C6B0074; Thu, 1 Dec 2022 22:15:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C22446B0075; Thu, 1 Dec 2022 22:15:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEA206B0078; Thu, 1 Dec 2022 22:15:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A16DE6B0074 for ; Thu, 1 Dec 2022 22:15:33 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 73717A06AB for ; Fri, 2 Dec 2022 03:15:33 +0000 (UTC) X-FDA: 80195900946.22.0F01C3E Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) by imf17.hostedemail.com (Postfix) with ESMTP id 0520140002 for ; Fri, 2 Dec 2022 03:15:32 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZTA6jNpY; spf=pass (imf17.hostedemail.com: domain of 3022JYwoKCPYwmqpwYfkcbemmejc.amkjglsv-kkitYai.mpe@flex--yosryahmed.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3022JYwoKCPYwmqpwYfkcbemmejc.amkjglsv-kkitYai.mpe@flex--yosryahmed.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669950933; 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=XH6mwHf7EDaGC67MtDUhfOFlBKrgBczQTfSrrHT2Rug=; b=yRqkDem5n6Lhhjnv8V0AcMIZxroM93kuiXBsyql3y+sbgjp6kj25EC5fB8EoYGWfaPKzmV GyGjF0ZXFpG+UltaMxgFAlLORkm4C0MwSmGvFdhyyXvx9d0T+i2qKhBdKO6B6nPaISQDu4 VE8g5YknfClEbUGlY8aihiGxMj3Whxs= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ZTA6jNpY; spf=pass (imf17.hostedemail.com: domain of 3022JYwoKCPYwmqpwYfkcbemmejc.amkjglsv-kkitYai.mpe@flex--yosryahmed.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3022JYwoKCPYwmqpwYfkcbemmejc.amkjglsv-kkitYai.mpe@flex--yosryahmed.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669950933; a=rsa-sha256; cv=none; b=QHpAwTC9KBgBdia1MCsVpwjLem4ZyLLb4bnjRjjttui8DnHKVdhjxxQj3BCCiEy9kFcfPD 42bmZbS3YFMBfXwJHbvMo5jQ5r1enfnN8f3Eeiz4iYnenaAf3T4PJkqfa45/Xg7jL3H+GY bwMvahuvXgolNKIWNvXKQ9E5QtQZtQQ= Received: by mail-pj1-f74.google.com with SMTP id my9-20020a17090b4c8900b002130d29fd7cso8178257pjb.7 for ; Thu, 01 Dec 2022 19:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=XH6mwHf7EDaGC67MtDUhfOFlBKrgBczQTfSrrHT2Rug=; b=ZTA6jNpY64q+OTD6IPuzuRI5YVchd2BVByQJxeZ+0jNgkDeRrpoOSkoYrs8JTmtO3d bQeuiSzvI8Ajv8CanGZU6FLXzkwcAwv8yy1vGr0fNUUydgPcY8g7mBvrUDpb0e/XO8fs T06y1p4yGVbIgmqg58n2Hwu6IDMMPHWVc0EEgdWfTYNjjs8rp/kWAwifEabu7DOLnPVo 8VTwxQgN+22poPKnK24M4MaFK+hfJ4iz2zC1d2eAK71nOT6Gep1QdONb5DEWjyPhqqtk JgQr59SzkaGqoo588LCfjHTJIbDJZ8Pyt8mGpq3V7fKVudzULA9iipwyeSMlqpqctAZ0 dNvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XH6mwHf7EDaGC67MtDUhfOFlBKrgBczQTfSrrHT2Rug=; b=eImCsEd0mXPV4u7vuKuuzi/1k7tLS5uCcvmhvK4UUfvVfOCYDWTSjGaidesG/cNsfS DQVTJ8j4SPTJ/bW8c0NMivRi6uzqTbyMxZAfWyxV7Y2l0V980ZuqmMeTSHfJOfU37HRM BUz4k0hNs8UhNn+kvq7u3+GGPORj8GK7wt7rFB2fvnKHyy1A263qWpsmYJ6GfzAN3UoG dEfhDQ0zMwhK/VZPXUxmPO7UWaGswJOrqClKLBy5wGRfcm5xNXD7Sft0U94nBmjyL22b K+zFePC3yVOEnedXFtw2na+jkEQwqfEYXfRtGmP0et3H9XCbdbLP5FR8laVQg/QJMJzQ 7Ufw== X-Gm-Message-State: ANoB5pnTElpwnxKpLZirOrPearna8L627k//xTtq+6QB1jXV0AY9Lym7 IzDAwTCXbZqG/mFU45mlvLGYqOpnBIh8aFxl X-Google-Smtp-Source: AA0mqf7PBETjtescCL3/FyX99YGmCALEDVA/h4FWTwolclKu6Pt0Ujihl1FAwjY7B0JyQYI/Hpzx3pIuupApd/fK X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:2327]) (user=yosryahmed job=sendgmr) by 2002:a17:90b:f89:b0:219:5b3b:2b9f with SMTP id ft9-20020a17090b0f8900b002195b3b2b9fmr1432190pjb.2.1669950931626; Thu, 01 Dec 2022 19:15:31 -0800 (PST) Date: Fri, 2 Dec 2022 03:15:10 +0000 In-Reply-To: <20221202031512.1365483-1-yosryahmed@google.com> Mime-Version: 1.0 References: <20221202031512.1365483-1-yosryahmed@google.com> X-Mailer: git-send-email 2.39.0.rc0.267.gcb52ba06e7-goog Message-ID: <20221202031512.1365483-2-yosryahmed@google.com> Subject: [PATCH v3 1/3] mm: memcg: fix stale protection of reclaim target memcg From: Yosry Ahmed To: Andrew Morton , Shakeel Butt , Roman Gushchin , Johannes Weiner , Michal Hocko , Yu Zhao , Muchun Song , Tejun Heo Cc: "Matthew Wilcox (Oracle)" , Vasily Averin , Vlastimil Babka , Chris Down , David Rientjes , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yosry Ahmed Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0520140002 X-Stat-Signature: fkxcetjdd9hno71ogwabr93cywkzbyri X-Rspam-User: X-Spamd-Result: default: False [1.90 / 9.00]; SORBS_IRL_BL(3.00)[209.85.216.74:from]; BAYES_HAM(-3.00)[100.00%]; MID_CONTAINS_FROM(1.00)[]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[yosryahmed@google.com,3022JYwoKCPYwmqpwYfkcbemmejc.amkjglsv-kkitYai.mpe@flex--yosryahmed.bounces.google.com]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_DKIM_ALLOW(0.00)[google.com:s=20210112]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17]; RCPT_COUNT_TWELVE(0.00)[17]; DKIM_TRACE(0.00)[google.com:+]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; DMARC_POLICY_ALLOW(0.00)[google.com,reject]; FROM_NEQ_ENVFROM(0.00)[yosryahmed@google.com,3022JYwoKCPYwmqpwYfkcbemmejc.amkjglsv-kkitYai.mpe@flex--yosryahmed.bounces.google.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[] X-HE-Tag: 1669950932-156248 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: During reclaim, mem_cgroup_calculate_protection() is used to determine the effective protection (emin and elow) values of a memcg. The protection of the reclaim target is ignored, but we cannot set their effective protection to 0 due to a limitation of the current implementation (see comment in mem_cgroup_protection()). Instead, we leave their effective protection values unchaged, and later ignore it in mem_cgroup_protection(). However, mem_cgroup_protection() is called later in shrink_lruvec()->get_scan_count(), which is after the mem_cgroup_below_{min/low}() checks in shrink_node_memcgs(). As a result, the stale effective protection values of the target memcg may lead us to skip reclaiming from the target memcg entirely, before calling shrink_lruvec(). This can be even worse with recursive protection, where the stale target memcg protection can be higher than its standalone protection. See two examples below (a similar version of example (a) is added to test_memcontrol in a later patch). (a) A simple example with proactive reclaim is as follows. Consider the following hierarchy: ROOT | A | B (memory.min = 10M) Consider the following scenario: - B has memory.current = 10M. - The system undergoes global reclaim (or memcg reclaim in A). - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() calculates the effective min (emin) of B as 10M. - mem_cgroup_below_min() returns true for B, we do not reclaim from B. - Now if we want to reclaim 5M from B using proactive reclaim (memory.reclaim), we should be able to, as the protection of the target memcg should be ignored. - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() immediately returns for B without doing anything, as B is the target memcg, relying on mem_cgroup_protection() to ignore B's stale effective min (still 10M). - mem_cgroup_below_min() reads the stale effective min for B and we skip it instead of ignoring its protection as intended, as we never reach mem_cgroup_protection(). (b) An more complex example with recursive protection is as follows. Consider the following hierarchy with memory_recursiveprot: ROOT | A (memory.min = 50M) | B (memory.min = 10M, memory.high = 40M) Consider the following scenario: - B has memory.current = 35M. - The system undergoes global reclaim (target memcg is NULL). - B will have an effective min of 50M (all of A's unclaimed protection). - B will not be reclaimed from. - Now allocate 10M more memory in B, pushing it above it's high limit. - The system undergoes memcg reclaim from B (target memcg is B). - Like example (a), we do nothing in mem_cgroup_calculate_protection(), then call mem_cgroup_below_min(), which will read the stale effective min for B (50M) and skip it. In this case, it's even worse because we are not just considering B's standalone protection (10M), but we are reading a much higher stale protection (50M) which will cause us to not reclaim from B at all. This is an artifact of commit 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") which made mem_cgroup_calculate_protection() only change the state without returning any value. Before that commit, we used to return MEMCG_PROT_NONE for the target memcg, which would cause us to skip the mem_cgroup_below_{min/low}() checks. After that commit we do not return anything and we end up checking the min & low effective protections for the target memcg, which are stale. Update mem_cgroup_supports_protection() to also check if we are reclaiming from the target, and rename it to mem_cgroup_unprotected() (now returns true if we should not protect the memcg, much simpler logic). Fixes: 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") Signed-off-by: Yosry Ahmed Reviewed-by: Roman Gushchin --- include/linux/memcontrol.h | 31 +++++++++++++++++++++---------- mm/vmscan.c | 11 ++++++----- 2 files changed, 27 insertions(+), 15 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index e1644a24009c..d3c8203cab6c 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -615,28 +615,32 @@ static inline void mem_cgroup_protection(struct mem_cgroup *root, void mem_cgroup_calculate_protection(struct mem_cgroup *root, struct mem_cgroup *memcg); -static inline bool mem_cgroup_supports_protection(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) { /* * The root memcg doesn't account charges, and doesn't support - * protection. + * protection. The target memcg's protection is ignored, see + * mem_cgroup_calculate_protection() and mem_cgroup_protection() */ - return !mem_cgroup_disabled() && !mem_cgroup_is_root(memcg); - + return mem_cgroup_disabled() || mem_cgroup_is_root(memcg) || + memcg == target; } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.elow) >= page_counter_read(&memcg->memory); } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.emin) >= @@ -1209,12 +1213,19 @@ static inline void mem_cgroup_calculate_protection(struct mem_cgroup *root, { } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) +{ + return true; +} +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } diff --git a/mm/vmscan.c b/mm/vmscan.c index 04d8b88e5216..79ef0fe67518 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4486,7 +4486,7 @@ static bool age_lruvec(struct lruvec *lruvec, struct scan_control *sc, unsigned mem_cgroup_calculate_protection(NULL, memcg); - if (mem_cgroup_below_min(memcg)) + if (mem_cgroup_below_min(NULL, memcg)) return false; need_aging = should_run_aging(lruvec, max_seq, min_seq, sc, swappiness, &nr_to_scan); @@ -5047,8 +5047,9 @@ static unsigned long get_nr_to_scan(struct lruvec *lruvec, struct scan_control * DEFINE_MAX_SEQ(lruvec); DEFINE_MIN_SEQ(lruvec); - if (mem_cgroup_below_min(memcg) || - (mem_cgroup_below_low(memcg) && !sc->memcg_low_reclaim)) + if (mem_cgroup_below_min(sc->target_mem_cgroup, memcg) || + (mem_cgroup_below_low(sc->target_mem_cgroup, memcg) && + !sc->memcg_low_reclaim)) return 0; *need_aging = should_run_aging(lruvec, max_seq, min_seq, sc, can_swap, &nr_to_scan); @@ -6048,13 +6049,13 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) mem_cgroup_calculate_protection(target_memcg, memcg); - if (mem_cgroup_below_min(memcg)) { + if (mem_cgroup_below_min(target_memcg, memcg)) { /* * Hard protection. * If there is no reclaimable memory, OOM. */ continue; - } else if (mem_cgroup_below_low(memcg)) { + } else if (mem_cgroup_below_low(target_memcg, memcg)) { /* * Soft protection. * Respect the protection only as long as -- 2.39.0.rc0.267.gcb52ba06e7-goog