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 436BF361974 for ; Wed, 23 Sep 2026 07:11:06 +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=IjiJF31ZTnp7xjHZJM4YHVaxy3N6WzIQZLtDYgH3Drs0IJYClp4ETaNfdPs5e/XgNEJmYQg3ykgDoekEAi5e/W3+SyfHjphEe05yW45tXClNi9tkevdYByuD3zPS8RZqT31vK82bdvIKMX+jASyawaxzlasXlN3CEe1C6xEMUmk= 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=e4K7mJVk; 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="e4K7mJVk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B92B11F008BC 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=1790147466; bh=tftRg/27iV6vOu9wnOe9xdmjMcB/et17gUJyLajCKAk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=e4K7mJVkpkC1fa5WHn0jgNxeZgLiKbJ0V2NjaEG3qzCK5AyydHhTDbey8BS+/L11W /2S046vecEhv/E5OwuYr37Y8lSMs1597S2iq3IQ/oI552uwUefIem5Tr61+VzhHBXX CGbk5246ul8BR45uuZbPESGnbhx5cvZyFhIxpkywKDMvmuPBL6D4EkTQis96rJbyyx 5aSM/icXeu7OwogW83YvJZe8jwGUcbuikeJ2plZxXoZOXUQ5bEqOXFwVeKuYokn2TJ LeRsbHsveLPQ1mfeIzgbE+giOj2h3y2bKpY9AQ8uLJdHaWgr5boSw5IMiA183DqQyY 3y1PR8hT30oxw== Received: by mail-yx2-f12.google.com with SMTP id 00721157ae682-85d43f9b119so10258047b3.2 for ; Wed, 23 Sep 2026 00:11:06 -0700 (PDT) X-Forwarded-Encrypted: i=1; AKwUvBw7ti+mpI19klNdv4Tdqg85PNDxfZgqXUYT+I2ZntAjliT1m4XqhGAQ55FHDvTTGBmTiXsKfQknIfM=@vger.kernel.org X-Gm-Message-State: AFuF++mOcPZffX87jbGu8J/l+DVS/XJknn/3YWf4uNSYs9lNrRvcgiim VBGQE2Bm0TJ8kXBte57PA1zzcbJIEGHRmi2bm1/6ehbFt3gpDWwAmIf1TgOOqZIeqPOQwM9cYo9 4DULOHcHSGSVHMZKz3uegSnPF9UE8ShkLXUQgLupjNw== 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-doc@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