From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-252.mta0.migadu.com [91.218.175.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A192358375 for ; Wed, 23 Sep 2026 16:30:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.252 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790181048; cv=none; b=PUfOHFwZ7FRB9lj7xTA0mXkn6uwJ9KV/lv8Ij080//0JiIyqBjcxXHJ2n+mQxs9hTtzpsyUDiEcmGAJjz6aX1NcjtaxHihUCymVgme7VW2P1wlMqt7L+bY+PKbqkWYy/NA176iyFmB6Ipkv+5MzTN4w8DWl1ZzvZtu8JAlNJOoM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790181048; c=relaxed/simple; bh=syhg4Xh/gTAUQZORWpezw8Y96tkhKRENMCokWTcj1JM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JocCe7Jw6NjuGYZxghfsb+XwmsYuY7Y8GbGFhct7OT7hv9V1Pj1a2svVqHY9lruelKlb/NqwN+bYFDP0PFIxoZxokWMVy47gaaiNanUCIx+T9n2fiYRKG5QNCxjQkGnqtnvNOnXon2aH2M+MrOFT9qcUUu7oyj9/np5hVaH6hDU= 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=e56fLXSO; arc=none smtp.client-ip=91.218.175.252 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="e56fLXSO" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=syhg4Xh/gTAUQZORWpezw8Y96tkhKRENMCokWTcj1JM=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790181043; v=1; x=1790785843; b=e56fLXSO0dNEodGCADCluJC7/pc7/Ch7AsscjvuEp0s8yNT9ctnnFUcVNBfkKs/yvhXeZ4rj oz+3SQnRv8I5zVPOixGqdMw7XDGU5t/zS1zlBWxqgk6IIDCS/AD/+IMr0lslwGcVvh6sM812+Cw wCAYqfllMyxTL7UQSjRjjpjs= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id a4693e8db12b2407; Wed, 23 Sep 2026 16:30:14 +0000 X-Mizu-Trace-ID: a4693e8db12b2407 X-Migadu-Flow: FLOW_OUT Date: Wed, 23 Sep 2026 09:30:12 -0700 From: Shakeel Butt To: Chris Li Cc: Nhat Pham , Rik van Riel , Baoquan He , Kairui Song , Johannes Weiner , Michal Hocko , Roman Gushchin , Yosry Ahmed , David Hildenbrand , Muchun Song , Kemeng Shi , Barry Song , YoungJun Park , Chengming Zhou , "Lorenzo Stoakes (Oracle)" , "Liam R. Howlett" , "Vlastimil Babka (SUSE)" , Mike Rapoport , Suren =?utf-8?B?QmFnaGRhc2FyeWFu77+8?= , Qi Zheng , Axel Rasmussen , Yuanchu Xie , Wei Xu , Gregory Price , Wenchao Hao , Jonathan Corbet , Hugh Dickins , Baolin Wang , Tejun Heo , Michal =?utf-8?Q?Koutn=C3=BD?= , Shuah Khan , Kunwu Chan , Meta kernel team , Linux Memory Management List , Linux Kernel Mailing List , linux-doc@vger.kernel.org, "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" , Andrew Morton , Kairui Song , Joshua Hahn Subject: Re: Path forward for Virtualized Swap? Message-ID: References: <7ee199ddee81bf8026688def82f78ad9db09be9e.camel@surriel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Sep 22, 2026 at 09:44:37PM -1000, Chris Li wrote: > On Tue, Sep 22, 2026 at 7:54 AM Nhat Pham wrote: > > > > On Sun, Sep 20, 2026 at 5:13 PM Chris Li wrote: > > > > > > That is not what I have in mind. The example I have in mind is that > > > zswap is charged to swap counters. Changing that behavior will break > > > our current deployment and that of many other. Kairui give some > > > example as well. That behavior should not change. > > > > We already have a knob to select vswap. Users can turn it off > > initially, and/or update their software to handle the transition > > based on this knob. > > > > Otherwise, you'd never be able to introduce any behavior into the > > kernel. Hugetlb accounting/charging is a new behavior, and there were > > softwares written before that assumed hugetlb usage is not charged. If > > it's not a good argument to block the implementation of hugetlb > > accounting then, it's not a good argument now. > > My original intent is that 200% of RAM for zswap is too much. > > It seems you are talking about a different topic: the vswap charging issue. > There is a golden rule that we should follow: don't break existing > users. At least with the same persistence, this rule should apply > universally. > In the swap tiers discussion, the UAPI was such a big deal that we > couldn't implement new UAPI. On the other hand here we argue for > liberally changing user-space visible behavior. Johannes has already answered this very clearly but let me talk about your other claim. > > BTW, I already shared that changing swap counter charging will break > our and others' existing deployments. What do you mean here by "break our deployment"? We are talking about memory.swap usage and limits here. Google is still on v1 and using memsw usage and limit and I don't see how vswap is breaking memsw? Are you making these false claims just to derail the conversation?