From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 4A4B44A441B for ; Wed, 14 Oct 2026 20:24:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792009486; cv=none; b=Uri3T3jP06W6xyfhK5F1TF+sMzayuH0H9GMOKjFmRnUUokjkReYbfEDY3NLLdzIRSbgsbuVdktyOV55R5eGwQNuQTRUBsVBSnX7YqL0F0JKvhLDSkRmVCN/g/dbpRODaNQJA5Gx6mX/syAIx0+t7Z8srquGtJBf/jX0Tc1XCkEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792009486; c=relaxed/simple; bh=8Y0NdDCiXwsCqs84YEB0iN+ue6zlIreIYv69VZZdj6o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j54gV0EHseILtcXc0Rxzy25tp7dNu+qKxrdfQf+JCQDMdPkB2WP0gePJ8Ejkcm0D0pzHPYqEBAOf6nbSPpWdMxf8yNU5r3PcZSQUcU7htVWoewajot4M7VSfr/89eLIqkyX7Fl8zbfDizdIySVGqqHdUzlawXOvpzGmnm6HCv9E= 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=dy5hDiey; arc=none smtp.client-ip=209.85.222.182 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="dy5hDiey" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-93ef9803765so252667085a.2 for ; Wed, 14 Oct 2026 13:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1792009483; x=1792614283; 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=AZpHrF8jH8WXu6WIXCauYQ4g5rjWW4oCNhs7abbw/eA=; b=dy5hDiey5/zTUojPi7BecClRfz26cM2FqMI5Bblc/wSv+JRfQVgFcj4bkJwTo4nRru jEGGoReOmP6c4GJIc+e3ls4jear0+m5DTxPP2ksf4bmjIoyvbAesiEXL07dut1J4gPvT JXCnNoSs0F9ogr4XCXZ0Aif6hc97gU9BCxvTRxU75F6U5w/kLXlSPMZPepCBha/OvlvO zjp4+21LAIBRmKv+DYMav9DiOS/o5Cp+yPskrwCSpbPWRqAysFIDTcHFhxeARLpCXaIO 8FpDrDz9ot4EeBwRyFMh5nfH0oJVozobnDOp0vaVsZixf4T7Kh8pr5sOmRwEkplYFYOg HiXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792009483; x=1792614283; 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=AZpHrF8jH8WXu6WIXCauYQ4g5rjWW4oCNhs7abbw/eA=; b=0k0z3IWEfSTWWQpZXNltZcsH23RgvkHTUbJuYHHlk97ecUycHW8pyc90/nJp0yBWhJ Ns+TG5B7z4HTyDOR6AlMCT3fDEwMcBijGIcdrEaFNJRqN7YOjZtU48Pf9g+ty19Nb/U3 oqkY5NKfZ6hllEn/MryJmduExZ4pYDaU/b4Jdk+plVI4L2IfVpiwoqWOoqaimr/1rRuM rY9bPeDDUi+/V7mnCbIoKXb+EZHf4mt73Liz8ggg4IUxEM0rFKZw6R5tguq5wT/489Is 5RaWQsutTZf5t9K2ublYBpEubydzntNzS9lJcarzzgJdJYa/uv1nUxXqWKJWFbV4XCHI Tu0g== X-Forwarded-Encrypted: i=1; AKwUvBwQ1LcpwoWg9qWfLluYdAbO1FG1gxiEs+S/aoPxRLNvp2AddZTNxi6wu8K9ejsJLAhyhQRgIZNebeY=@vger.kernel.org X-Gm-Message-State: AFq9FYI9yYeVABIGv5K41wJ/sjd205DdP3GEdgexJlIgZFVUe7lV/5Kw awTpSaRHY9kozHsEpL7Ve5RwOGBRsYJgSa11Jq/htc/qX/PsOT4mvYbRp7AaksLZFz0= X-Gm-Gg: AYBFou1skwShUJeHYKAl0mb9EAOJpa+JNIGJJUI4ZYr/IENYNCIAHjKaHCq566S0piN 5mHKVthp6UKhD8rm9tkd2HWQyNNbkLUHeyR40juFpv9VKTDMgiHIHOXr0GGc1oq9bYy0V6XN+Yn Ud6v8yTwekh3LXFbw6J/OQG3hyyxmCuMHj6PIhpefvUeqIVRshMYG507MKMOkDySJkm0E0HTSN9 RWj/wL2jHg+6iTPNXnw0YZ2z3W+orBmZbSayjj7beYYS1wSLVrElupYUr5yr7VDFXHj1CWAKThP SKWpdsErl1/vqm+87V+bKJcqX3pMaL7LMniHUG8LUxCDlC/edoNO6NCSGW1zh4XXedC+SWkrnEe P0CmZ+GQnafjQhIDIu/kejYH+g7ahOmGXfKNJFLILjCW2VJnZ3+u7UkhsuSUtTDzStqGKuFI9lv 7yUrb7UuFpy1ybpxvAjkqaaVmK+nG7QGe/F7qEm+2j5jI+P3E+plpKvR7eXuxDv88KqbLo X-Received: by 2002:a05:620a:a0cd:20b0:93e:c12c:f149 with SMTP id af79cd13be357-93ec12d0893mr1925202885a.83.1792009482638; Wed, 14 Oct 2026 13:24:42 -0700 (PDT) Received: from localhost ([2603:7001:f100:5081:9526:3c0:45cc:5ac6]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93ef4f49861sm582813585a.4.2026.10.14.13.24.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Oct 2026 13:24:40 -0700 (PDT) Date: Wed, 14 Oct 2026 22:24:35 +0200 From: Johannes Weiner To: Kairui Song Cc: Chris Li , "David Hildenbrand (Arm)" , Baoquan He , Nhat Pham , Michal Hocko , Roman Gushchin , Shakeel Butt , Yosry Ahmed , 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 , Rik van Riel , Gregory Price , 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: <20261014202435.GB371161@cmpxchg.org> References: <5ca344de-bc34-4a9b-ab85-f553811a1d9c@kernel.org> <5c8a2b7b-b76d-4bba-92e1-ec3d66794273@kernel.org> 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: Suren, if you've not been following this, there is a question you might be best equipped to answer below. On Thu, Oct 15, 2026 at 01:17:21AM +0800, Kairui Song wrote: > On Tue, Oct 13, 2026 at 1:27 PM Chris Li wrote: > > I understand that you have some face-to-face discussions at the > > conference. Do we have a list of what has been aligned and what is > > pending to discuss? We should have an agenda to avoid repeating > > already aligned items. > > Right, from my perspective, here are the following key points we can > discuss further in the incoming meeting (most of them are not fully > concluded yet): > > 1. A limitation for the logical size: from my side, there are real > usages for a global non-memcg limitation of the non-physical swap > space: e.g. thin VMs as containers/pods with no cgroup limitations > inside but which need in-VM memory compression and a proper limitation > to avoid thrashing; or low-end devices/desktops that want global > (root) limitations. And also, Android have a limitation on the ZRAM > size (well for this one I'm not from Android team though so that's > just my personal development experience with Android, enlarging the > ZRAM size on several Phone swill cause serious junky of Apps due to > over compression). Android monitors psi to kill on excessive pressure. This should capture thrashing from over compression. Suren is CC'd, we should get his opinion. > Nhat is concerned that exposing the sizing allows users to tune it and > potentially misconfigure the system. However, I think a user with root > permission should be fully aware of what they are doing or they can > easily mess up the system in many ways and swap limitation is a very > minor concern to me. > > I think the requirement for a logical non-cgroup limitation is strong, > but the discussion hasn't concluded on the implementation method. > Perhaps something like a Kconfig combined with an interface or command > line? More ideas are welcome. I agree that overcommit control can be useful. But there are setups that implement pressure-based policies and do utilization monitoring just fine from userspace; they have no need for logical overcommit bounds inside the kernel itself. *Defaulting* to a static limit and/or making a choice mandatory seems like a mistake to me. It would make more sense to treat this as a related but separate problem. I'm happy to brainstorm solutions. But we should be open to discussing this from scratch - userspace monitoring; an extension of /proc/sys/vm/overcommit_* etc. > 2. Charging: If you consider memory.swap is physical only then indeed > we should not charge it, however, user are already doing that for > years so this is a behavior change and we are also pushing memsw into > memcgv2 as a interface to limit the logical memory usage of a > container. So charging of the logical space is useful, how to handle > that is tricky though. > > From our usage, this should at least not block adding memsw or > anything similar for memcgv2, even if you want more customized cgroup > accounting, we need to charge it into some counter (a page counter, > not just a statistic) in some way. A path for memsw in cgroup2 is generally unlikely, actually. It was intentionally split into separate memory and swap counters and not forward-ported as a combined control. Like I said, we should discuss overcommit control from scratch as an orthogonal issue. I'm happy to do this and help find a solution. But I want to get out of repeating that this is not compatible with cgroup2. > 3. Swapoff: This was discussed again too, as vswap was trying to > remove it. I think the concern is mostly about maintenance, > performance, and practicality. From my perspective it's a critical > component both for preventing minor or major faults before predictable > high traffic arrives, or for operations/debugging, and for releasing > the swap metadata to rule out any potential swap / page fault effect. > There are concerns about maintenance or suggestions to use MADV, while > I'll be happy to explore and improve the current in-kernel > implementation of swapoff later if needed but removing it is a really > bad idea in my view. Here too I think we should be open about discussing the problem and what a solution could look like. "Swapoff" seems to presume the virtual space in the shape of a manageable swapfile through standard interfaces. A separate knob to clear out the vswap space would accomplish the same functionality without pulling in the entire swapfile interface e.g. > 4. Writeback: No doubt we all agree that we definitely should have > writeback support, Nhat's concern is that we should handle the case > where some cgroup doesn't need zswap/compression and ensure that works > well. +1 > 5. Interface: Given the issues above, what should the interface look > like (swapfile, sysfs, /proc, etc.) and how should multiple > (non-physical) swapfiles be used? Nothing much is discussed about this > part though. I've heard users mention the use case of multiple > compression swap spaces, but I don't have a use case for that myself, > so I don't have many comments. +1 It would be good to collect usecases first. Interfaces are forever and we shouldn't add them on speculation. > 6. The one part that I think we can and should agree on it shat the > implement approach: at this point I think VM_SPARSE is the right > direction, Nhat is concerned about the testing on it, and I think we > can have more data for that, and collabration is highly encouraged. I > previously conducted many tests on everything posted from both sides, > will try to post more on this too. Here I think we're actually least aligned. The VM_SPARSE implementation requires a static size, and prior discussion has made it clear that we actually have no consensus on how to pick reasonable values - be it in the kernel or in userspace. The xarray proposal requires none of these choices or interfaces, and nobody has been able to show that it's actually a performance concern.