From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk2-f42.google.com (mail-qk2-f42.google.com [74.125.230.234]) (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 E46DE4B826E for ; Mon, 21 Sep 2026 15:49:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.230.234 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790005745; cv=none; b=QRQNvcFRXN2ey+LC70OVQTvzjGMGbVWnUkTxq1V8MwEPweMCG5FbsaT0zda+5ajpW+BgZLN9A8EXdh+jh1dIRkXKqYqr+9qAlVv0My0tFs9s36s+fbrHNCQjcVDkJDyCKBFQOVCrWkL7zfqzFcwuxCqmW8qAOR0OL/YjI1V0V2s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790005745; c=relaxed/simple; bh=7X8DglpYoKyJvznThs0j4mHe4fvO4f+WYWYfsETxoTw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sFwCUA7fVfSqxUIc6xaugwQeciFCc2E9EvgL+FvJSckjyoDL+hqZdgAAu9DZ8NAyDVSVZzSdsMCZQjvi+3gK64Bcvy3AaHwjNmhgmEo4ZBrfyyNRVEYEdWpfamKfXoJK9j6KDpk3dqzUQA5yRygdVW3MzjAuwj1PSXmZF/CqWTI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=BIZAXQEY; arc=none smtp.client-ip=74.125.230.234 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="BIZAXQEY" Received: by mail-qk2-f42.google.com with SMTP id d75a77b69052e-5329fc7b325so21026071cf.0 for ; Mon, 21 Sep 2026 08:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1790005742; x=1790610542; 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=/s9qiYogYW6WNzZt1dtpYbULGoaZUSl75Lwvowk+5Ug=; b=BIZAXQEY/Wt5INkxOWj6lymS27vi7/z1sa0MgKHnqBoqUzHhK8b4bl38ZaoOrKcU6A O1DPes8GpyzoWexQY/RMIT455kXxs/n1GFqSWa0q5JBeEKq1rqWJ6NN0TkZ6W5OE13zc ipNmI3SstNNExVm3Lqr0c4MDYRI69JsuSQvDyqe8hkf3GJUB4bGpk4NfKg5vIyJ1u1MI T52Qjsh3sAvaSJkowkdS1RRabwCSK+HxelWuvSfhcsG4dytku/EMUh4/MCfkDET3m1Z8 b8MjxsApOlDfcpVd28m1Oy/ly6TDn7B/g6eINj3lebGSX0LUZOUlI6cHtDIckQdvKOm9 +Gug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790005742; x=1790610542; 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=/s9qiYogYW6WNzZt1dtpYbULGoaZUSl75Lwvowk+5Ug=; b=h9zDoM9skH2CB2WF14wCibs1N2aNDCpwG6fPcVkE9wJ+IZTo3Ul11n7ObzK29nxMiv 8rSHdX8GZVL4VeaT9HwD4ND3hRzR2080gZQIQ1RwJUBC1D9rqI/Y23vK7TGdbBVcgLk+ eLWNu8/nlCAtMscMkcI8CD4ndJWKrD9m8gCbE956+19t4wYaLtNs7Vayt0Z4otHke/Uz gsQguMcLyjfPsI28hEc3XHXXX5z6YOCuyFLwenGhJ8mhcuUk5Yq2bKpP8lGD2rozpGF3 8SQWE0819OcCgHRlJPvxfnqoGIgek2qls9CayPGzPBGbI7cNJA3T/0ELVjBLFKDsVdeV I31Q== X-Forwarded-Encrypted: i=1; AKwUvBz1ungd1uPnZBmFf5lYKYEo1FN5WMKC57M03Awr4dLgg3I58/gdNSktHlAt1aCFISjvgLToFnhMtEjWyog=@vger.kernel.org X-Gm-Message-State: AFuF++nQvSxq+LawDTP+gi7sPgmIXwq5QBWbw896brO7F9DS2xS38GKC ZeFSThqfjLtJhOEIZaNFcpIlA6tnoMtzS7zLlRoSm3S+4bbineeMn1YkQNvRM4C4NQM= X-Gm-Gg: AYBFou3S3D+UuXSuwf8+2l0oOa1jfVfHO+QUon2T7ZPTmuTjAVhIFoGHkh6lV5TTQgk Y5PvJyWXhxgpAipF/I0ddlWJSc3M+m24JUZcYJLS8ogMMet9LzdQNCK6aRYzHYyOD+kuy/jD4TL +3LROIUkycJ7GeKNID38WmmtDc3ql3ut/LUXghrFJSZ+cIm0AjU4HU+x/k6ehBmFSx2aWCmSspj LqVu4rBmMrKNUM+jooqtGzk18zWChlWcCu2UsFNvZgQ6VfKDUfCobMVuz9LlCX9QOQxcng74hon w9pytudYvhW2a9hy48Yr6T7vk5GSzcNYQM5YBLEW0j+2/RPDmeuKBa9LrMwVGBgtiyy4D57sD4r kSmG/pgddd7Ew2gKrT1qPtITnbk0P4eesDRUhknDnDIGsQQ+XHv1fYntSCr5B/uGI6Fjob7/8bu 1FHoOOfGY16vafVU6Pn2YHpGk46U+O1HKU7uItq7o0YDQ/09IUvFA25JLQz2OYv2nXOvQeujx4N DQHugaDM0E= X-Received: by 2002:ac8:5a8b:0:b0:532:a5f4:df25 with SMTP id d75a77b69052e-532d8e4f628mr13379251cf.57.1790005741711; Mon, 21 Sep 2026 08:49:01 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F ([50.193.156.113]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532ae512550sm66992481cf.1.2026.09.21.08.48.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 08:49:01 -0700 (PDT) Date: Mon, 21 Sep 2026 11:48:57 -0400 From: Gregory Price To: Rik van Riel Cc: Kairui Song , Chris Li , Johannes Weiner , Baoquan He , Nhat Pham , 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 =?utf-8?Q?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 , Joshua Hahn Subject: Re: Path forward for Virtualized Swap? Message-ID: References: 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Sep 21, 2026 at 11:27:53AM -0400, Rik van Riel wrote: > On Mon, 2026-09-21 at 09:27 -0400, Gregory Price wrote: > > > > In short: > > > >   memory.swap   = logical swap       - workload/SLO limit > >   memory.pswap  = physical swap      - storage limit > >   memory.zswap  = compressed memory  - RAM limit > > > > This would preserve the existing memory.swap semantics while allowing > > both backing resources to be constrained independently. > > > My first thought was "this is confusing", but > after a minute I realized that most users will  > never set those options to anything other than  > "0" or "max", and the few who do only need to > touch one of them. > In practice, at most two (zswap + pswap) with swap=max. There's not much of a reason to set swap to anything other than max if you already have zswap and pswap limits. But for existing users where they're using it as an SLO signal, they could continue getting the existing behavior by just using swap.max. That said: I'm not convinced this is actually required, because the swap counter was never an SLO mechanism - it is a physical swap provisioning mechanism. If it's being used as an SLO mechanism, those users have misinterpreted its documented meaning. memory.min / memory.low already provide you this logical limit mechanism - so I would argue the parties that want such a split (rather than treating zswap / swap *as* the split) need to prove their use case cannot be supported by existing counters. ~Gregory