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 59736C433EF for ; Tue, 12 Jul 2022 22:52:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB6679400D6; Tue, 12 Jul 2022 18:52:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3DED940063; Tue, 12 Jul 2022 18:52:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DF7C9400D6; Tue, 12 Jul 2022 18:52:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7C1F5940063 for ; Tue, 12 Jul 2022 18:52:32 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 4DF468034E for ; Tue, 12 Jul 2022 22:52:32 +0000 (UTC) X-FDA: 79679948544.01.E1227C1 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf14.hostedemail.com (Postfix) with ESMTP id E06151000AC for ; Tue, 12 Jul 2022 22:52:31 +0000 (UTC) Received: by mail-oi1-f169.google.com with SMTP id v187so4454826oie.7 for ; Tue, 12 Jul 2022 15:52:31 -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=htaxsmbLkerK/WzSwDGnn60xtZCz4ZbFlZTWngCZmEo=; b=PJvAiv/DmAKyikrJij5JE66g75DNqz4DHzNmHd/JdP5z0zk7MZqnCrSzDvKAn/vIHL /D1NSeoCJVH6odh+Uj/o+s5cBf7HLPhJcKRVVRRPWXogWz+S1pndViMAUC1Zvw5ESZAP a4uDkbnnM/6ytDcaYwsBLjwLxeO9Rih93Gr+RXKEKTPt1wqx/q0JXbde46/8Bpzm1NLV 78Bw7c0NvdCwXjhEsfKVunNKJ9ihm2+YXJqQWj5UFZzKq30VoqbtCJCBYX34Eh3+yLHx tX5KytQJPfANtkoIvguy1zTKRUksrSmQqW7JiP3kjvDh4jRUVC8MV/aTs5+JNNpJOxnR 3ZKw== 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=htaxsmbLkerK/WzSwDGnn60xtZCz4ZbFlZTWngCZmEo=; b=b43qkQ1LHBTVYcHs4EyZV1B0J7b5oxRb+X7ov5QOPwI77o8qM0RC58W6NFvldUJkib flLph7BArL2kYJ/bOfn/P34H/7S71QVbKOrieP+x4+vXi8/uKxUB1xtDkMfyvDHASzB9 B8k8ABtn4l1d11eAyuujUrVUhvbYW7BcizovayQVPVQgaVgHSfI5IkUpic8E16z7qf95 prv2hNqtrrZWlFW+8FTam/iCEA+Uy9umJbX7/HX0gyDc5VpE+YkIjeQCK2Q+/NgqykU4 44tlOoaRqli3SksILDOIkYUgDOvAAEGpEADZKLksHh1Y3gKI7u8EXYY51w3M67ydgID9 l8mA== X-Gm-Message-State: AJIora+kvX4yFcB5+AQZO+I8KvAhSipa6axWpNrtJpS5wWPz3srH0SO9 l+DVTIOevtjFuySSU+qMh4J7GJBWuaNqA9tnxsl1ig== X-Google-Smtp-Source: AGRyM1v5ZQYkfQFzh3Q+CTwzVWkW3rKZ4YQSPbjjNofA8KjFTYODA3mdjroafcnyMFZaGWXf9o9yfeVXNks1gmZ3kmU= X-Received: by 2002:a05:6808:1a10:b0:335:9e39:693b with SMTP id bk16-20020a0568081a1000b003359e39693bmr216623oib.165.1657666350921; Tue, 12 Jul 2022 15:52:30 -0700 (PDT) MIME-Version: 1.0 References: <20220630083044.997474-1-yosryahmed@google.com> <20220701160947.e4902e5b0484ed084db5d41f@linux-foundation.org> In-Reply-To: From: Yosry Ahmed Date: Tue, 12 Jul 2022 15:51:54 -0700 Message-ID: Subject: Re: [PATCH v3] mm: vmpressure: don't count proactive reclaim in vmpressure To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Matthew Wilcox , Vlastimil Babka , David Hildenbrand , Miaohe Lin , NeilBrown , Alistair Popple , Suren Baghdasaryan , Peter Xu , Linux Kernel Mailing List , Cgroups , Linux-MM Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657666351; a=rsa-sha256; cv=none; b=clzAsIbbstALLCrdxf/6sVhTqXCAwF093aMYlU5R+Ki+0+/e8BMCZBVXnWJ4RFGymw8GAF fSD9OA02JlQAvtq18BclA5asGaF+jT1AkEIDihKjZHRdnwbY8Y1TUumBwqQ+5ekcOfaRBr 4k+4dmSYOzyhKDlf3gExgNKLVCtdyeE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="PJvAiv/D"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.169 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=1657666351; 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=htaxsmbLkerK/WzSwDGnn60xtZCz4ZbFlZTWngCZmEo=; b=mdG9foCbhnDVdTWZjQfU/mS9bee+2/YMCQedvQYI2Hiz9p21t4FKNCi8MBjBsBb0VOHIm/ jDsGOvddN6GUgYxReif/Eh2ZdOHQxGCXN5kZciUDLem44twwRY2AudzHa7VTKYdGZyj2XP VLzVVjdPmYqcs2/iD3/466e19bHfgS4= X-Stat-Signature: trsnjbngrkcox7sh3a9ms9iznxexdg7i X-Rspamd-Queue-Id: E06151000AC Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="PJvAiv/D"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1657666351-394575 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, Jul 6, 2022 at 1:19 PM Yosry Ahmed wrote: > > On Fri, Jul 1, 2022 at 4:09 PM Andrew Morton wrote: > > > > On Thu, 30 Jun 2022 08:30:44 +0000 Yosry Ahmed wrote: > > > > > vmpressure is used in cgroup v1 to notify userspace of reclaim > > > efficiency events, and is also used in both cgroup v1 and v2 as a signal > > > for memory pressure for networking, see > > > mem_cgroup_under_socket_pressure(). > > > > > > Proactive reclaim intends to probe memcgs for cold memory, without > > > affecting their performance. Hence, reclaim caused by writing to > > > memory.reclaim should not trigger vmpressure. > > > > > > ... > > > > > > --- a/mm/memcontrol.c > > > +++ b/mm/memcontrol.c > > > @@ -2319,6 +2319,7 @@ static unsigned long reclaim_high(struct mem_cgroup *memcg, > > > gfp_t gfp_mask) > > > { > > > unsigned long nr_reclaimed = 0; > > > + unsigned int reclaim_options = MEMCG_RECLAIM_MAY_SWAP; > > > > > > do { > > > unsigned long pflags; > > > @@ -2331,7 +2332,8 @@ static unsigned long reclaim_high(struct mem_cgroup *memcg, > > > > > > psi_memstall_enter(&pflags); > > > nr_reclaimed += try_to_free_mem_cgroup_pages(memcg, nr_pages, > > > - gfp_mask, true); > > > + gfp_mask, > > > + reclaim_options); > > > > It's a bit irksome to create all these unneeded local variables. Why > > not simply add the constant arg to the try_to_free_mem_cgroup_pages() > > call? > > > > I was trying to improve readability by trying to have consistent > reclaim_options local variable passed into > try_to_free_mem_cgroup_pages(), and also to avoid nested line-wrapping > in cases where reclaim_options = MEMCG_RECLAIM_MAY_SWAP | > MEMCG_RECLAIM_PROACTIVE (like in memory_reclaim()). Since you found it > irksome, I obviously failed :) > > Will remove the local variables where possible and send a v4. Thanks > for taking a look! > > > > psi_memstall_leave(&pflags); > > > } while ((memcg = parent_mem_cgroup(memcg)) && > > > !mem_cgroup_is_root(memcg)); > > > @@ -2576,7 +2578,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > > > struct page_counter *counter; > > > unsigned long nr_reclaimed; > > > bool passed_oom = false; > > > - bool may_swap = true; > > > + unsigned int reclaim_options = MEMCG_RECLAIM_MAY_SWAP; > > > bool drained = false; > > > unsigned long pflags; > > > > > > @@ -2593,7 +2595,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, > > > mem_over_limit = mem_cgroup_from_counter(counter, memory); > > > } else { > > > mem_over_limit = mem_cgroup_from_counter(counter, memsw); > > > - may_swap = false; > > > + reclaim_options &= ~MEMCG_RECLAIM_MAY_SWAP; > > > > reclaim_options = 0 > > > > would be clearer? > > > > I feel like the current code is more clear to the reader and > future-proof. If we can't swap, we want to remove the MAY_SWAP flag, > we don't want to remove all existing flags. In this case it's the > same, but maybe in the future it won't be and someone will miss > updating this line. Anyway, I don't have a strong opinion, let me know > what you prefer for v4. Andrew, any preferences on this before I send v4?