From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 437B1381EA0 for ; Wed, 23 Sep 2026 07:11:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790147468; cv=none; b=fSEC96k1/J/zxVIsRF93CDIHwlIum7oh3QwPNTTvawbubpLaaqsMEhfzo1RbUcogptFdhbdN7Z2H6QmzaEXSAXEG/qKRq2214wCbyV2IU7u3Mvb4N1ZxVuydWXyrkm+FVnOrAn34QH1oV0phMZNWxeeiI8jhvUpu9zDnyrgB7ZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790147468; c=relaxed/simple; bh=tMhv2qOhzG4jrkkzinGONLyAHB+FkZzKXBAXmbOVLII=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eDvg/sz/QOVxgB2jKRQso5AWrTkyTv5iA8aE8VzexyaF3J+dndgHlw3jNBe4HVL8uXMa9BWyrs79vQBIyt5BX929U4YDUEvnSzt3qsxP3E/RrI4M6GAfyu+kyzlB921HLEP/ssClWIF+if+jDOdAVzviPYsXY9ijoSvvGQnTsxk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Sf2gvYC1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Sf2gvYC1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E820E1F008A3 for ; Wed, 23 Sep 2026 07:11:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790147467; bh=tftRg/27iV6vOu9wnOe9xdmjMcB/et17gUJyLajCKAk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Sf2gvYC16i7t3y1+CNEEDaFYEerMmIMhLoQE4kK8OddmpLkHpPFIB5kpnUCmi3Omw ic73erqLgRSRCVpjsi6z6kV+s0+YG6p+eOxXKzXjirZd95RKvRgBW0fQXDNdm+ml6d BKinEvNLADOfwhOkBWou2UasFo05YixEqK7j0mbDqvBBxFnMU4ap+cUeiKsKIzW85a zmbIskaAs8TCIlTPISgaIggHTHIpYcQ0uCHkkVEDOWbTPGIaH4ffBnbrnS1KPYzjYR 4/EMdDUAoZAHZr8pdzA12UxVQbX/J444BMbLwPVEu5eiuRfB3f7eWrtgqjCZhL7NPL 5neo3NiKWjS7A== Received: by mail-yx2-f12.google.com with SMTP id 00721157ae682-85d43f9b120so8789437b3.3 for ; Wed, 23 Sep 2026 00:11:06 -0700 (PDT) X-Forwarded-Encrypted: i=1; AKwUvBxRXTYo9/vRb2zNgFbTMhndN9SlP1UmzIkbrzbJAa1UZVIB1ACWy54dWJxSEQpwTtLbUK8DYJPZCXyb5zY=@vger.kernel.org X-Gm-Message-State: AFuF++n4d1tKxj8hFrXTpiSvRVv/zrMn8/Z1LNDZ9YKKmKrh7A8++Fjs mP8wiqr67asKllFJ1BOGhmezTor6Gy7MgPuOLqWFaDSQGJOwmMCIyX/8rXUbQfYQ0ge4ODirHQJ N+1WcSaR3dL4LNaD76RksT7shgc+Ryy+0gqhq26u7+Q== X-Received: by 2002:a05:690e:b4a:b0:66f:c1be:3186 with SMTP id 956f58d0204a3-672d59e6f9bmr769388d50.93.1790147466000; Wed, 23 Sep 2026 00:11:06 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <785353ef79844e81a8cd97e87b00ef1f785b15e5.camel@surriel.com> <83539be885f15bb567b30264f5f62e718f4a9fd0.camel@surriel.com> <5a7ad159b2fabf377b7e1fc4248c433287ac11fb.camel@surriel.com> In-Reply-To: <5a7ad159b2fabf377b7e1fc4248c433287ac11fb.camel@surriel.com> From: Chris Li Date: Tue, 22 Sep 2026 21:10:53 -1000 X-Gmail-Original-Message-ID: X-Gm-Features: AcwNN1UwLMqYNrXn7OTzxPK_RQ9DWuqFMbs5fykDFtZyEsnuAKIyTcjTdWAUOSI Message-ID: Subject: Re: Path forward for Virtualized Swap? To: Rik van Riel Cc: Gregory Price , Johannes Weiner , Baoquan He , 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 , =?UTF-8?Q?Suren_Baghdasaryan=EF=BF=BC?= , Qi Zheng , Axel Rasmussen , Yuanchu Xie , Wei Xu , Wenchao Hao , Jonathan Corbet , Hugh Dickins , Baolin Wang , Tejun Heo , =?UTF-8?Q?Michal_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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2026 at 5:53=E2=80=AFAM Rik van Riel wro= te: > > On Tue, 2026-09-22 at 05:43 -1000, Chris Li wrote: > > On Tue, Sep 22, 2026 at 5:20=E2=80=AFAM 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 =3D 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. > > > 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. Chris