From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7E723537F6 for ; Mon, 8 Jun 2026 21:19:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780953584; cv=none; b=czkXFVdeXgNAVGGCMsJjQUG2eNyN7ayseM9dZgBDLoBlCS8qlu/s9z5w6SgqOeQUxCjx16SqeFKUN0/S64ktz0LTbxjTXYUbGqz5ac42IWyd6WVTsBJKajfx6tNA7mZfbxUoMU3Cg6B5x7piUm2wLh6lVOQBBWcl/ZAxVueZ3fM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780953584; c=relaxed/simple; bh=f1Z1McbAZj67FRERk0tg/Z2N7a0BiKa4ITNwffu0X5E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ae4RayN9Wa434xfU0wVcy2IPn7T6HMc1q7lEJEZqlSg4j6W0I0pzEeBcSWu++GAxqmw7lRgbZEQTryBgYDJ2BGuP4enBelKc9IfMoKqPKZhrXr+hX337EURqT+8BuDzYr6MbnpVhthOQeTIIgn8DgXteYrsbpyYcnEfY7ty+qms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Syr8Mk8V; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Syr8Mk8V" Message-ID: <744aae62-ad99-4534-906e-92ddad978ee1@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780953579; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ec90fDW6R1sxEf3CKA876D/56qUgFC7LMDsU+008II0=; b=Syr8Mk8VuYBPuflxy2C5a+UzMAxzS2VQ7Z/rDte8Wea1S+sZyARjZHSFqQCG/9wawqPSle mseN3YCCbFVrGJn+n3/CLJ1yTpWTd0pYGf9NJSrkQC3L9Gq3wEiyUkuyao95bnHpoTy4fy bgm7AUI4gXHGKSP9R4O+mMFYCkl2O6Q= Date: Mon, 8 Jun 2026 22:19:36 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 0/2] mm/vmpressure: reduce CPU, memory and code overhead on cgroup v2 To: Shakeel Butt Cc: Andrew Morton , david@kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, tj@kernel.org, mkoutny@suse.com, 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 References: <20260606114158.3126210-1-usama.arif@linux.dev> <750406a5-1819-4ca6-81d8-5a1d82e0644b@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 08/06/2026 20:56, Shakeel Butt wrote: > On Mon, Jun 08, 2026 at 07:49:45PM +0100, Usama Arif wrote: >> >> >>> >>> For this, I am wondering if we should just go ahead and work towards making >>> vmpressure memcg-v1 only unless we foresee a lot of or complex work is needed >>> for that and only then patch 2 makes sense. >>> >> >> I think there might be a transition needed? Because vmpressure and PSI >> do not work out to be the same and people might notice a regression with >> increased memory usage or a hit in networking performance and might want to >> opt out? A solution might be to switch socket pressure to PSI while >> keeping vmpressure around gated by a defconfig. And then in a few releases >> remove it completely for cgroup v2 if no one complaints. If we go down that >> path, we would need patch 2 for the medium term. > > Yeah the reasoning that PSI is not an exact replacement for vmpressure makes > sense and it will take couple of iterations to transition v2 (networking) away > from vmpressure. Can you please update your commit message with this and about > the midterm or transition plan. > > I assume eventually we will just have vmpressure-v1.c file which will be behind > MEMCG_V1 flag, correct? Yes. How about something like below in the commit message? : 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 may regress networking performance or increase memory pressure in workloads that today rely on vmpressure's hysteresis. The medium-term plan is to introduce a PSI-based socket-pressure path, keep vmpressure available for v2 behind a defconfig as an opt-out for several releases, and only then drop the tree=false path entirely, at which point everything that remains in mm/vmpressure-v1.c is the whole subsystem.