From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk2-f15.google.com (mail-qk2-f15.google.com [74.125.230.207]) (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 39E0B478847 for ; Fri, 25 Sep 2026 21:53:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.230.207 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790373213; cv=none; b=k9VLEEGADI2emT9Bd87LGri0nsXLM6rzFW5kpwEa91NuHVATNiteFujRDIsBf3UYTwZs2mq4lqrgEIps/2WG0aQ9P4ium3iiNKxOUGXtFuSS4TdGKD3r/7jokPGGqOnJOQXef/zwj6pm4iTdYYJtXVatz/WVVp0DPY2gu4RKLMU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790373213; c=relaxed/simple; bh=kBHykIA9B5ogeVV0Ds8QGLkMdL7AcZ2GU8m5t3bk8DE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hdhXfdwxpNp4knF5Uv/0ngmjRjcm/mRSVPEPKADpdWUIhjZyKDfbO2CU6ymuoCEUok9xaunI+MkHO1wdqti21n3bUuvaaNwKLS+/2wmWSnjGQFQ/pR/+eeXMGRtnngC9xIzVnhY/5MelnSrD9OHmdVmJtdM5a9FuSviTJh0gQVA= 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=uwyFVX/I; arc=none smtp.client-ip=74.125.230.207 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="uwyFVX/I" Received: by mail-qk2-f15.google.com with SMTP id af79cd13be357-93910c3d02aso62778585a.1 for ; Fri, 25 Sep 2026 14:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1790373210; x=1790978010; darn=vger.kernel.org; h=in-reply-to: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=TJzCvfxmeFB1cEl2za6t85fQGoyj6ML9WfPxvW5p3nM=; b=uwyFVX/IKwJOXkmMdNzAkiaAQ03UyZ1v2ZFmbdTRVO+oicNub/rgWomg+Smwh+m0/J SY/Q6k2BJ+LrxWjQzrjB/h0u4wkpLGmAqMFxdxpbU7GGYuK6E79Hnw/GXQX1kp9hHf+g S4FP1X60smvEor3805GYFJ47q01UfMytRnJRQCvfuUzWmf9sabwN4htiY8uqTJea+CfJ xpC0FPojdJMZ++fxqkAXjKshpo1Ir6r+GGK8B7xYy79/JuZG+A+UUu+1njuEXQHgQitW iWFLxxCPG7AD2U/Z33MJkGM5+zPAoBar18KPOHOgX34/oga0+8V31IPCNccpCS8knrKU x0qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790373210; x=1790978010; h=in-reply-to: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=TJzCvfxmeFB1cEl2za6t85fQGoyj6ML9WfPxvW5p3nM=; b=IgaskRaK0WKU2H9FoALsIlJ9oHdqeHCA+kvu0zxQjZ5HnkmOA6U7f6SE45ngebZet1 QFpSScZ+Bj3IVzy+hVmdxnodv/vRnYKPBJODxP+kW6Lg0NH/BIxdiPz7/VmFztY1fWCx FKUOyC47z/DIMyDrJ9KW6hAz3yJnfB8eYIif7Uv1tkGenYySvHlXKJdq4nRNp3IOIXEc i6DcQZSGyqhrUPG7FnMDQ4b587PUSEVainerVfOvyhrP2qC0bv5A5h+hr/cD9eGWDajY +VkEdlHH07+17fRaWOOEPk2UzSDIk4Ru6TW3ieen83k+9/LDtNhAARBMMq1rTVHiX79b ai8w== X-Forwarded-Encrypted: i=1; AKwUvBzjYobBqHxBhd4XtzPuXaPtNb7PF9quzbx67frwCUoGxjZpnC7yHDwev1+H0ZMLMceZ/+4JsWcx2pU=@vger.kernel.org X-Gm-Message-State: AFuF++lqUBeUY8L2QyuAlLfUcZ7Gv+/+odGGSqt1D9jFxOvyepfmiVpF j1WggCw+udb7JIO18G7+UYdGFsMyuwsnPY52kYnxIFLsfZPliC8sTaY4CLaK8jVTPls= X-Gm-Gg: AYBFou1Qbn901PVe9Kg8TL20CggdvX4Uw6cwuNeVMam+tjHB+bTglLy2Secz0F14CZp 0FsWXPiJYfKkCesxNUbDRFSlIYonLX5SD0XXnKabgjArMkH7+WqufrrnUWwzq5Go4McYeVKnAw8 eaHhnuaVK7o+sYJDCsLxiLnz2IBLPR105eFjcPJh6EI5Jj7nXawcqka6QZwZlSqYnm5jbiiRzcu rhWX/oDLmwZltewkGLwfoOp0CUqU5QSvex0PXyrDkoGjxFxekWisSGJMbi9I3UI7ApVRiAjATHF bd9K5LWnogdmxmRpFOi9cbH2cE3fxM/lu08XTsYKgB0dirN8nI8jwcB3AFBPIzOAxMGCa0Xs6gw 3lVQ8c5QLJt4cvaeTDsazMEVqJTZ8JxHyG4EdtsMi54w+hitiUR609y4Vx7Z/XtjI9Q4zr9FXep 8X6VJQSwLirJwtkZ7PTMBUDo8wXkM89K2/hWNFz9lMLwOIj69G98APKdIyx+7GVvUzGY8VM1snd M6nc7zE X-Received: by 2002:a05:620a:4398:b0:936:cd75:8f91 with SMTP id af79cd13be357-93c43c44d65mr740709185a.12.1790373209889; Fri, 25 Sep 2026 14:53:29 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93c44653c8bsm277775485a.3.2026.09.25.14.53.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Sep 2026 14:53:28 -0700 (PDT) Date: Fri, 25 Sep 2026 17:53:24 -0400 From: Johannes Weiner To: Gregory Price Cc: Kairui Song , Chris Li , Nhat Pham , Rik van Riel , Baoquan He , Shakeel Butt , Kairui Song , 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 , 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 , Joshua Hahn Subject: Re: Path forward for Virtualized Swap? Message-ID: References: <7ee199ddee81bf8026688def82f78ad9db09be9e.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=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Sep 25, 2026 at 05:30:03PM -0400, Gregory Price wrote: > On Sat, Sep 26, 2026 at 04:44:07AM +0800, Kairui Song wrote: > > On Fri, Sep 25, 2026 at 12:11:55PM +0800, Gregory Price wrote: > > > That shows up as stalls and PSI pretty quickly and can be dealt with > > > by monitoring - but I can see the desire to just have them OOM. > > > > Right, monitoring is less effective from somehting that is directly > > in the kernel. > > > > Well.... I think this is probably an organizational philosophy. > > We are pretty solidly effective with PSI + proactive reclaim keeping > our machines chugging along nicely. I think this is where a lot of > confusion is coming from - because the PSI data is very effective. There is also that we usually don't add convenience things to the kernel for what can (easily) be accomplished in userspace. The job of cgroup is to contain and isolate workloads from each other. But you're not hurting anybody else by overshooting into compression. It's a lateral move within memory.max. > > > > The second one is a policy change, > > > > > > Disagree. > > > > > > If zswap does not charge a physical slot, then it is correct to stop > > > charging the counter based on the historic definition - it just was > > > > Hmm, but the historical defination is the logical entry, no? > > > > I think this is the entire debate, right? > > Historically I think it's clear that it is a physical slot, from the > time it was proposed it was talked about in terms of consumption, and > Johannes' original definition even said "physical" (for some reason > this did not make it into the docs). Yes, it's physical. Cgroups partition physical resources. That's the whole reason WHY cgroup2 doesn't have memsw to begin with. It's not a resource. CPU cycles is a resource. RAM is a resource. A swap partition is a resource. A NUMA node is a resource. "Unique page table entries" is not. That's a metric or a constraint that you might find interesting for your workload. But it doesn't have anything to do with partitioning a computer into containers.