From: Usama Arif <usama.arif@linux.dev>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
david@kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org,
tj@kernel.org, shakeel.butt@linux.dev, roman.gushchin@linux.dev,
liam@infradead.org, linux-kernel@vger.kernel.org, ljs@kernel.org,
mhocko@suse.com, rppt@kernel.org, surenb@google.com,
vbabka@kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v2 2/2] mm/vmpressure: split v1 userspace eventfd code into vmpressure-v1.c
Date: Mon, 29 Jun 2026 16:20:10 +0100 [thread overview]
Message-ID: <fb9af391-b991-41fc-a105-7a3008860c07@linux.dev> (raw)
In-Reply-To: <akJ-It8m_xm1WVLY@localhost.localdomain>
On 29/06/2026 15:29, Michal Koutný wrote:
> On Mon, Jun 29, 2026 at 02:55:57PM +0100, Usama Arif <usama.arif@linux.dev> wrote:
>> On 29/06/2026 14:34, Michal Koutný wrote:
>>> On Mon, Jun 29, 2026 at 05:59:37AM -0700, Usama Arif <usama.arif@linux.dev> wrote:
>>>> This split is the first step toward eventually making vmpressure
>>>> CONFIG_MEMCG_V1 only. The v2 in-kernel socket pressure path
>>>> (tree=false) cannot be removed today immediately: PSI is not an
>>>> exact replacement for vmpressure, and switching networking socket-buffer
>>>> back-off to PSI
>>>
>>> (Here I understand PSI is a different and differntly scope metric) but
>>> what does it mean when you write that tree=false cannot be removed but
>>> the other patch bails out from vmpressure() (i.e. nothing is updated
>>> anyway)?
>> So the first patch bails out for cgroup v2 for tree = true only.
>> For tree = false, it doesn't bail out, and is still used for networking
>> socket-buffer back-off. I think that is a whole another scope of work
>> switching to PSI. Hope that makes sense?
>
> I've mixed mutliple things together, sorry. I wanted to actually ask
> about your response:
>
> | I realized when trying to swap the order that the splitting off v1
> | commit will end up doing more that what I think it should do (just
> | splitting off v1 specific code), as the tree = true code will not get
> | compiled in at all for cgroup v2, and it then ends up changing more
> | behaviour.
>
> tree=true won't get compiled but v2 doesn't care about it, so the effect
> of patch 2/2 should still be same (regardless whether it comes 1st or
> 2nd).
> Do you refer to the invocation of vmpressure_v1_account_tree() that is
> affected by this?
So what I mean is that I want to keep the effect of the patch that splits
off v1 code as just that and not have the optimization of not running
vmpressure for tree = true + cgroup v2.
vmpressure_v1_account_tree() compiles to an empty function in the split
patch for cgroup v2, so if we make the splitting out v1 code as the first
patch, the commit is not just going to split v1 code but also do the
optimization of not running tree = true cgroup v2.
I hope it makes sense?
>
> Thanks,
> Michal
next prev parent reply other threads:[~2026-06-29 15:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 12:59 [PATCH v2 0/2] mm/vmpressure: reduce CPU, memory and code overhead on cgroup v2 Usama Arif
2026-06-29 12:59 ` [PATCH v2 1/2] mm/vmpressure: skip tree=true accounting " Usama Arif
2026-06-29 16:46 ` Johannes Weiner
2026-06-29 12:59 ` [PATCH v2 2/2] mm/vmpressure: split v1 userspace eventfd code into vmpressure-v1.c Usama Arif
2026-06-29 13:34 ` Michal Koutný
2026-06-29 13:55 ` Usama Arif
2026-06-29 14:29 ` Michal Koutný
2026-06-29 15:20 ` Usama Arif [this message]
2026-06-29 17:13 ` Michal Koutný
2026-06-29 15:57 ` Shakeel Butt
2026-06-29 16:48 ` Johannes Weiner
2026-06-29 17:23 ` Usama Arif
2026-06-29 18:12 ` Johannes Weiner
2026-06-29 18:28 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb9af391-b991-41fc-a105-7a3008860c07@linux.dev \
--to=usama.arif@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=mkoutny@suse.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox