From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx2-f43.google.com (mail-yx2-f43.google.com [74.125.224.171]) (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 8448F52B1FE for ; Wed, 23 Sep 2026 14:11:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790172712; cv=none; b=liB0tOnSKAQzPKbMTS6WitnQFb6ROUj98BYFRHUb8q/GvJO6O8ekWoF+fXZo+x36l281SXm31OzmEDuuw9VklVDVrv9k60wtrvO6d6Oik4soj7E7Htk8TQ2hUMsseY/WyuL7oJFal72ugGEEK50QJy6WMMAoR5jI5T1psmlXeq4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790172712; c=relaxed/simple; bh=LGkkGMO9TERbEvKb8FRwlBQ0y/VcZh7QYYRvUrUUVgI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Gz5s/HpXu0xzgpSRLfgpOdUr1e7e0Quvnxl5yVwaVMCzxgpdyV84Votl41QqGx1X9S2sbFFrhJeIObf4GyXg+ulkBwzOIwsQjKWB3zZDKkiE53nvsgQTzP1zgZWTlExwTSqqkeI6pli9UqvaYEegqPcikwW1OnuHHsu3Pk6RCd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=PXIaWXRp; arc=none smtp.client-ip=74.125.224.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="PXIaWXRp" Received: by mail-yx2-f43.google.com with SMTP id 00721157ae682-85d43f9b120so13154487b3.3 for ; Wed, 23 Sep 2026 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1790172708; x=1790777508; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=f7LX2hgCSw8Eo3VcIXgLYrzvPbWMXRZn6yDRkmN7Gj0=; b=PXIaWXRpfdMN1dWxL76T7IGNzWwT1jFAoAeoqw4qgOcsevgKXY6Xu5LIS9/4fHhptH hz3NaQI6+AHCLwfAaRMyyVxPdQT9PvoAJB135dna7knuRHzS34RsUuISpAsk/adV6eDi mOibJWB8ODVC2Vet9ZQKUbV4Ghzm17vCkPVWLjNm0S/KIKkWA4aNaBjV5x2uB+wGLoNE 1CHOdYdgCVPbbmN2f+AjW91W/79lChW3pFCLkbsypCxenmLkNyoJwmQ2PFbVFIlvYNIp p6tvEx2DZOFJ31aPqamHnyvF4GRXoS8hrmlD6fIl42WxeOR2t5dso3yvtlipv8hDjG8p eJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790172708; x=1790777508; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=f7LX2hgCSw8Eo3VcIXgLYrzvPbWMXRZn6yDRkmN7Gj0=; b=vl71jdtoqiIHL9c5ErWtSJUG6p+FRvEGRTnirno+C+2bqeqxlfZkxYNNSbXpMBdn7e pgmTfNOKbV+1a+zVEQCkeRHWtWdmTlX2bi4A0uxLrlUMBjqhKdIFJ+AyePVls5v5JvQZ VSLU+0BAogYewD6lX41wNJq3v9n7b1qxCnBIF1gv1IgxirBcJ+/bb/kHAiesuTh94tOk l/vFGZuVzQ/qCCA6sdGIHw4jvctCinAQyEqRuDCZriagwjznGQ5Jky/PaCF5Jf2YMFHT xdF0uBzZq1/dVAKzfaNLn3e+p8RrbqgNWwvYEth7js6OUBd/Kz1kPj9IZWXLaMz83eNT CXSA== X-Forwarded-Encrypted: i=1; AKwUvBy12cMnPafuvCcbnuztys64QSTF1sRZz6VN8dYu9nXvApWbCLsh34lK4acz+CG4mLlTGORH5yHAFXk=@vger.kernel.org X-Gm-Message-State: AFuF++klnxxUZVM0l36iuwaxQEdr1/PESukUpaJoD+AqWpmANxHELSQI k+r4bFqDMxNs7GDN0OxTH4TbAXNQI7eIHBT3dFFQVtf59TaZN3iz+Puo19tUmGo4aeo= X-Gm-Gg: AYBFou0eY7xfys8FanBHgXggXbrzBJMYEMlJBE99XaJCT0KYEx1ICgSbO2JwFhp9NPM AmMlCmnLIf1erUSowAFITdS2wQE8FnrLcoPKO6Xr8SMdjjkG5IYYGaAUy4VGs6943Ww9rtCosQV xtIIh6gpnwuEiYHFgYkUEu5pa54iNddupbMu9h3pmEF40B5lqDrxvX/UeLWyPMjWhTJyP2n+SQn XsC9qo9sMEhnSkFn+wMr65tGx0oTmecg+iVcEV5LS7/gEp8yAt5q6Ornsa4OWm6pN0hSG4DhYhb b/tTEpGD9JPJWGGUSHruNsVBH5eN8hIrjyq+jYRxNpka2q2/XJPGFF2OYaPPiFNcfsVhaKgEwoV IWjiCDEiPqCcQQTPPY3S9uq403OdOVocKTMJJ5wwFjUGq2E+qwDTOK+wQb3dxg2M7J9cxXf7Rqg 0jILHZaLK90M4889hZXdJIcfVt5nu5bK0S8XmfPB56KOzNXTFEYZakJ1DmU+oxF9Y/MSKZ14x4n gR/sNQ= X-Received: by 2002:a05:690c:5705:b0:89a:63da:faaa with SMTP id 00721157ae682-8a45c8372f3mr11122287b3.101.1790172708255; Wed, 23 Sep 2026 07:11:48 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532eb3396f6sm20644991cf.19.2026.09.23.07.11.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2026 07:11:47 -0700 (PDT) Date: Wed, 23 Sep 2026 10:11:43 -0400 From: Johannes Weiner To: Chris Li Cc: Nhat Pham , Rik van Riel , Gregory Price , Baoquan He , 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> Precedence: bulk X-Mailing-List: linux-doc@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:37:48PM -1000, Chris Li wrote: > On Tue, Sep 22, 2026 at 7:33 AM Nhat Pham wrote: > > > > On Tue, Sep 22, 2026 at 8:23 AM Chris Li wrote: > > > > > > On Tue, Sep 22, 2026 at 4:59 AM Rik van Riel wrote: > > > > > > Yes, I can agree on what you observed. You are using anon + zswap on > > > that app alone. That is not what I originally asked. > > > > > > My original request was for the whole system: what percentage of the > > > total system RAM size has been swapped out to zswap. > > > > > > Because when you have 100% of zswap out, it will likely trigger > > > different kernel code path on allocating memory. You might suffer > > > global memory pressure you did not observe in the single app memory > > > pressure case. > > > > What does this 100% figure refer to? Pre- or post- compression size? I > > legitimately cannot tell. > > The 100% I mentioned above refers to the pre-compression size. See my > previous email in this thread for details. I have been asking for a > max(%) number in your fleet for more than six emails now. Because people keep telling you that it's immaterial. The job of the compression layer is to make pages smaller. It has no business deciding what is "too much", what is "too hot". That's the job of reclaim and OOM killing. That's the job of cgroup residency controls, of things like MGLRU's min_ttl. You have absolutely no way of knowing what a safe threshold is for every usecase now and in the future. The argument isn't we need a bigger limit. And I refuse to haggle with you over what the precise value should be. The argument is a to use an xarray and keep making pages smaller while the policy layers deem it reasonable to do so.