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 ADBFCC43334 for ; Wed, 6 Jul 2022 20:20:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2C526B0072; Wed, 6 Jul 2022 16:20:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDB7E6B0073; Wed, 6 Jul 2022 16:20:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACAD26B0074; Wed, 6 Jul 2022 16:20:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9D7346B0072 for ; Wed, 6 Jul 2022 16:20:34 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 731E0346E0 for ; Wed, 6 Jul 2022 20:20:34 +0000 (UTC) X-FDA: 79657792788.18.D79A695 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf03.hostedemail.com (Postfix) with ESMTP id E483F20013 for ; Wed, 6 Jul 2022 20:20:33 +0000 (UTC) Received: by mail-wm1-f54.google.com with SMTP id be14-20020a05600c1e8e00b003a04a458c54so9570292wmb.3 for ; Wed, 06 Jul 2022 13:20:33 -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=zN05oMg9A5eMExVvuhLNwOOx17/+XHETTJXVnUtgWnA=; b=T6LSPKDIQlfkCde1dkkcPrJsSgkHNqUSJpiXKz/0vT1OX0fc18YBReSbC51uYTchM9 /gQT9y8WsL8XZQPIyiTT2IU6yDNYMTHbdkW4gKnLR0WEBfSxw0mcKXEyrIVwnn6Bov8U IpqUrIX6zjWpKYr3tV3SGFvdrx2ZvGxsSPDVC7jOAeSy6CcZtY//HpliLN50I4rR+KpV xW/f9UEvQHE52zXqJGyZKMr7jZhWHUAs9uWPj51w0ZZFp8GYPDTG3N3b8v9O5wyBf2QR RD0vMPEqy0M85Z3kt0tDYjQre0PGe7u18n6V4HvBonyimUFpLgkq7R0p1ENxG7VI13To 8fEA== 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=zN05oMg9A5eMExVvuhLNwOOx17/+XHETTJXVnUtgWnA=; b=fc5mp3/s0Bci9MTEsjXoPAD2UfMJh2MvItBOSEvIfh8V9ceQYuVIdEHuN8mCy9aAyJ 9buBN/KykmHzyhzO3dyvdYazW/5pYozUHAmcBRgW2bK29umPD+TBF2P3wsD1pTjOSY+j 4MqDJYxIFeRzIpKQg4m9AQK0wqfKIoXQfAGaNRpm609S3qMLab/LAlkt4S2YK49fU4Lu MXrD4sRv2eI8xlqMADd1/wZq9g2pWKOxvjIL3tdEuIeWXQvUI8hq2x8EKPyE4U9KCdTF nxda4Nwz3kF15KE2FygufrUfGolTsr4TSzZ0eMBo/W6U8G9hGvU2hGcA75T/ww2AwWKU TE2g== X-Gm-Message-State: AJIora9vPwrAO56nFDqpNXczqLbzs7hUktVB+IL5TfyxWsKp+vvAlrCK OOT4VrMeBhkTvUD0eLJRih6xMwTcgr5Iyss37rsLOQ== X-Google-Smtp-Source: AGRyM1uHudEeLtBIqriGM1ShXbu7TbT6VofLjKwqY3M+ttN0eioirnkaGM47kiambaWwwsJG2xJ5dDvyBP0v3Qw4IKA= X-Received: by 2002:a05:600c:1e8e:b0:3a2:c1b4:922c with SMTP id be14-20020a05600c1e8e00b003a2c1b4922cmr417065wmb.24.1657138832379; Wed, 06 Jul 2022 13:20:32 -0700 (PDT) MIME-Version: 1.0 References: <20220630083044.997474-1-yosryahmed@google.com> <20220701160947.e4902e5b0484ed084db5d41f@linux-foundation.org> In-Reply-To: <20220701160947.e4902e5b0484ed084db5d41f@linux-foundation.org> From: Yosry Ahmed Date: Wed, 6 Jul 2022 13:19:56 -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=1657138834; a=rsa-sha256; cv=none; b=Ay52iGgF85zR4WQ+77iYuToueOETbd1XBLnMjToZha/XvhSFFxm4nnDKTS8VjpL8w6MBkz +KkLP8z6+RnGuy/Z07IRqO+xxtlPXz29kcLbij4+uUhoVVhWGQ/iJvifOoyFwcKZbDan1n 1nuA/8eK99pyaQAlBRMMak6vxG2jHf8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=T6LSPKDI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.54 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=1657138834; 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=zN05oMg9A5eMExVvuhLNwOOx17/+XHETTJXVnUtgWnA=; b=fY4pHof6lVRWxYroS2g01aw9vWiy3jYscBfiQk3WblhAM0QEFt8qWwiTSxfdUFjIPyX99N WwX0gmMbSAbpSWOjPmleTqQBcfd2A5DhNh8LxTk/onVeGP7NYp3gu7+iHZd/sQs7ZzQupD X0NP7Q0GdQSub2HVTw2DqW2qZafB7Fc= X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E483F20013 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=T6LSPKDI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Stat-Signature: k65z7dnxsn7z48biw534y3zyjdtowu8e X-HE-Tag: 1657138833-22717 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 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.