From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-44.mta0.migadu.com [91.218.175.44]) (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 893C43161A1 for ; Thu, 24 Sep 2026 05:51:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790229117; cv=none; b=MyId1WTy/yZTsor54q1u+0W5YQ9Ayqd0Ys7i32FtNjX/sANgLdMnShtnqexNbFR/Y4rN+fJ8LVVnAY6uKiIHZTuiy7ZWESQIz04JfuPvpgGh1izFlK577zZLbGq9qdt/FqA7sc8gi9voOsVSB3QKoCcG/YzPUDeU+xIc/uiQQek= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790229117; c=relaxed/simple; bh=Qh8p1Wq/6FENjB4kTXNkMpLip9RVFvwk/eduC06xJC4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p9Qxhoo+vUj1XOKYlccnVDszMsnJfFdLwqjrlVZhJs28VdGP6cJDWWW6QEdNiM2TeEvnDQilbAYwhutxqw7HvMYwwQOFn+0yYEgRdnnRz4lyaeSgEAKw1fTDYUfL85HqnTNi2SIlDlpBJ/s2T6uuJ8Qk3Tjz6W+rAGXQACi13PI= 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=sP1vWwUl; arc=none smtp.client-ip=91.218.175.44 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="sP1vWwUl" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=Qh8p1Wq/6FENjB4kTXNkMpLip9RVFvwk/eduC06xJC4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790229113; v=1; x=1790833913; b=sP1vWwUltxM/z61RttITi1TTXJcaD5qmwVoAGCwAH6bUAhg+1oKaDYiP+Cx3RM9SgwVFvEmq TIATMENnAhTTqe9J34sC+epd7JmzmW6vzuTUnL8Eu+Bxz0qFhMcgSZOSoVAMBvJ5EL8Rr7seKSy nQtHO6IQ+KYN4R0qxzdZW+sc= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta12.migadu.com with ESMTPS id f5f74063f00ab3a9; Thu, 24 Sep 2026 05:51:52 +0000 X-Mizu-Trace-ID: f5f74063f00ab3a9 X-Migadu-Flow: FLOW_OUT Date: Thu, 24 Sep 2026 13:51:50 +0800 From: Baoquan He To: Klara Modin Cc: Chris Li , Rik van Riel , Gregory Price , Johannes Weiner , Nhat Pham , Kairui Song , Michal Hocko , Roman Gushchin , Shakeel Butt , 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 , Wenchao Hao , Jonathan Corbet , Hugh Dickins , Baolin Wang , Tejun Heo , Michal =?iso-8859-1?Q?Koutn=FD?= , 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: <785353ef79844e81a8cd97e87b00ef1f785b15e5.camel@surriel.com> <83539be885f15bb567b30264f5f62e718f4a9fd0.camel@surriel.com> <5a7ad159b2fabf377b7e1fc4248c433287ac11fb.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 09/23/26 at 02:52pm, Klara Modin wrote: > Hi, > > On 2026-09-22 21:10:53 -1000, Chris Li wrote: > > On Tue, Sep 22, 2026 at 5:53 AM Rik van Riel wrote: > > > > > > On Tue, 2026-09-22 at 05:43 -1000, Chris Li wrote: > > > > On Tue, Sep 22, 2026 at 5:20 AM Gregory Price > > > > wrote: > > > > > > > > > > On Tue, Sep 22, 2026 at 03:32:44AM -1000, Chris Li wrote: > > > > > > > Right now it has 64GB of memory. > > > > > > > > > > > > That is exactly my point. You are running 1/8 = 12.5% system ram. > > > > > > > > > > > > > > > > Chris you are missing the point > > > > > > > > > > Zswap: 8812236 kB > > > > > Zswapped: 24927876 kB > > > > > > > > I am well aware of the point. The 7%-10% data I provided is before > > > > compression. After compression, the real saving is about 1.5% - 2%. > > > > > > > Here I'm at 28% without any issues, with room for > > > more. > > > > 28% is one thing, 100% is a difference beast completely. If you > > haven't tried it, don't assume 100% will behave the same as 28%. There > > is a point where too much zswap makes the system unusable. It is hard > > to pinpoint the exact upper boundary. However, figuring out the upper > > bound larger than that exact boundary is not hard at all. I haven't > > seen any one can use 100% system RAM sized memory swap out to zswap. > > If you have a data point showing what that system with 100% swap to > > zswap looks like, please share it. > > > > Chiming in as more of a user perspective. > > On my 4 GiB BPI-F3, I can reach more than 10:1 compression ratio on > zswap during some parts when building GCC 17 snapshots. E.g: > > MemTotal: 3966864 kB > SwapCached: 31872 kB > SwapTotal: 16777212 kB > SwapFree: 16638128 kB > Zswap: 280140 kB > Zswapped: 2859840 kB > AnonPages: 2927376 kB > AnonHugePages: 1409024 kB > > While this is 72 % rather than the 100 % you asked for, I think this > shows that what size a potential limit on the uncompressed size of zswap > is suitable heavily depends on the workload. > > I have been using vswap consistently on all my machines since about > August, and I have also tried one or two versions of xswap (but the > current lack of writeback makes it inconvenient for me). I really Thanks for testing xswap and reporting issue on xswap rfc v3. xswap has writeback now. I only built foundation for xswap, while writeback part was left to other people for collaboration. Finally I added it. [RFC PATCH 00/17] mm, swap: xswap writeback to a physical backend https://lore.kernel.org/all/20260920072043.430390-1-hebaoquan@kylinos.cn/T/#u > appreciate the work being put in to decouple zswap from needing a > physical swap device to work. > > > > > > > > You are not listening. The boundary was set due to feedback from the > > > > application SLO. Those are real deployments not imaginary usage. > > > > Please respect the user. > > > > > > > Different users need different things. > > > > > > The kernel needs to be able to accommodate all of them. > > > > > > The kernel default should accommodate the people who > > > are least capable of configuring their systems. > > > > > > Hyperscalers can set their own defaults across their > > > fleets. They know how to adjust settings. > > > > They can use a safe value, e.g., 100% of RAM. Let the people who know > > exactly what they want to swap configure the boundary they want. > > My personal preference would be for a default uncapped (or very high, > and I don't think 100 % of RAM is high) limit on the uncompressed data > which is backed by zswap, since that would mean one less knob to tune. > > > > > Chris > > Regards, > Klara Modin