From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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 5A74638A9DD for ; Tue, 10 Feb 2026 18:52:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770749581; cv=none; b=q5xuXhfaOSEcaUN0gzWrUrQpqJ61FHFCw/9YAoTl3HxDS982ZZFD1uVTaoS63gzPDSCoGKfeRknEGm9OwBQO76Gn6GvY/h1BZweUd6bhfQMwlEzmfJAlBC2g0lTzDjzFpG0esu7MRx46WWtFjR1XygSU46K3VIK/RC9Ckn2GTss= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770749581; c=relaxed/simple; bh=2M+aBL+xwIjke2RBYrRF+nVdMsjWO5VVoMXLUs63K5w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LzE74qYV4Yp9PSVJdDSVn5EZsvxfPgx3HS9tHZyvDSRuI3KUJnmh5aRtSDPXyoZHQNPTkFEeX6fIE0MsGhQiqfkZLrz2ozlBsXNqVA74yJC3Mao4340eIgFi/XKsexZKZ8K/L3sykKguODdwCKJ3/wORW+jHRCLtKdAaEvUFDGU= 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=ZPYSjFSz; arc=none smtp.client-ip=209.85.222.172 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="ZPYSjFSz" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-8c70ab3b5fcso605634785a.2 for ; Tue, 10 Feb 2026 10:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1770749578; x=1771354378; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=dYxAK4MfxkNTvDSky4rly7XqGqYb657cJCOkNsVbPkc=; b=ZPYSjFSzo0LI5+2mg7yQ1l3Y0w+fbxoBOsYscmkcIQw4Ip6+OuFlOc1HCTEKS4euqK uZGpCAamX7ThxS63/SpJlHXvfsb5oxlNIS4URcwdog+ldFOMjrbCTedZZx8JfnopPmQ2 cwhIH5mYhKrpgnXROdB1jr/JP7FiaNjaRQ7J+VxbRpuQO/gb0K0P1IHDnfKulFKEExFF Uw6HpWhiAsu5eqkrz5wir8dre3siFDyyK1ZrehfbYqy9pMaziqrGfLgVpRHcTelUaac1 ZImXTbFQVR+chNfoG326fkznH41ggq6K6WnXOOCsDvGO+Ns4nan0rRlZFAVbqbP5e93R qgcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770749578; x=1771354378; h=in-reply-to:content-transfer-encoding:content-disposition :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; bh=dYxAK4MfxkNTvDSky4rly7XqGqYb657cJCOkNsVbPkc=; b=thG0SoRNGTidvapi5IjNVAtDiKwwCQFYoimHk8RdL6zm6KEYxmiLG3QMT9H/x1+sN6 GJDg1WrCr4yGB1JBoasrBelF98cgZXus24TVrf1MgIqyLoDiJX1HcAC4+P0NPZwYOGop oktPc14WFuMYvRC/DW7NpVb9O/u9eebWor2aGfNP6/OSqrklXauqAt7nRadOmEU0lNM5 4mJTUyrgfVhWnn78LHfVhFrnwyb+4VUrM1rU1nt6GVOlNqtuIjU076m3RJShOHunjuxJ CinT6TqMItQt4Pegt9xEn9xhmeLwzveUWS9m2j4rjw2c2cdktskPFK1KtZ8BP113w4pN CyEA== X-Forwarded-Encrypted: i=1; AJvYcCX9mln0B9h4/vYWjmLvk6sXJsdhjOiKJEl+w0oe8CZFBjQT4QNrzHl0rd6k6GoGcOMN8srH27qN99tGCTg=@vger.kernel.org X-Gm-Message-State: AOJu0YxraqvP2kMVE54666ABMgKj0UPX0vrv1u4X/jE1b/n2Kg0phjRs cOyJ8lX6bgxCBkalwGlMfw+Obt8OMGkjGc/wK9218CewtSJTvTmCnZgQH9sI27jr5Wc= X-Gm-Gg: AZuq6aKDewI0TbjxBepY0JzXcZMdP31MfMUrsCRuwQrac+YRHwwlKfGSOtQUi9CP92N F8ybMy8Xonl6irtClzQ1FnCr13QyvdB1Pdi1fj1ftC+5DY7Gcfw9YzSAolMtTzN5Cvq89e+MSRZ TLnz0txXOr0v1vbwcUFPnQDft026GJFIoEyc+N3rrb3HW1XjcVbJEYYta4x+ZH2t22r2M23U0ND 4c4TGFnFZ2fysG22uCAUrfIO2PeIOHmVUTu2P0CKy4QlZQg5oCthfSQH3e/XtXwrZnpoeFT5m7K EnsidErmP2dBSQoy9yWD8gVzhKJVrDxIWf6IVb5T+pR8CK5McLPffk+mZKL+b0Ch/LGk96VI2Di GO06svFlMB4xvfygL/tL2fdp982c1b4k4dn/UP2gDIQwyO3YWqOIeUnvAgAVcZHOM3TqBszd0sf DFIxTRMrOoBU8qyVk4ND1vM2xmZJmGQkw= X-Received: by 2002:a05:620a:690e:b0:8b6:1877:3689 with SMTP id af79cd13be357-8cb27fc2b12mr39809385a.35.1770749577839; Tue, 10 Feb 2026 10:52:57 -0800 (PST) Received: from localhost ([2603:7000:c00:100:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8caf9a16240sm1107793485a.35.2026.02.10.10.52.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 10:52:57 -0800 (PST) Date: Tue, 10 Feb 2026 13:52:53 -0500 From: Johannes Weiner To: Kairui Song Cc: Nhat Pham , linux-mm@kvack.org, akpm@linux-foundation.org, hughd@google.com, yosry.ahmed@linux.dev, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, len.brown@intel.com, chengming.zhou@linux.dev, chrisl@kernel.org, huang.ying.caritas@gmail.com, ryan.roberts@arm.com, shikemeng@huaweicloud.com, viro@zeniv.linux.org.uk, baohua@kernel.org, bhe@redhat.com, osalvador@suse.de, christophe.leroy@csgroup.eu, pavel@kernel.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-pm@vger.kernel.org, peterx@redhat.com, riel@surriel.com, joshua.hahnjy@gmail.com, npache@redhat.com, gourry@gourry.net, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, rafael@kernel.org, jannh@google.com, pfalcato@suse.de, zhengqi.arch@bytedance.com Subject: Re: [PATCH v3 00/20] Virtual Swap Space Message-ID: References: <20260208215839.87595-2-nphamcs@gmail.com> <20260208222652.328284-1-nphamcs@gmail.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hello Kairui, On Wed, Feb 11, 2026 at 01:59:34AM +0800, Kairui Song wrote: > On Mon, Feb 9, 2026 at 7:57 AM Nhat Pham wrote: > > * Reducing the size of the swap descriptor from 48 bytes to 24 > > bytes, i.e another 50% reduction in memory overhead from v2. > > Honestly if you keep reducing that you might just end up > reimplementing the swap table format :) Yeah, it turns out we need the same data points to describe and track a swapped out page ;) > > * Operationally, static provisioning the swapfile for zswap pose > > significant challenges, because the sysadmin has to prescribe how > > much swap is needed a priori, for each combination of > > (memory size x disk space x workload usage). It is even more > > complicated when we take into account the variance of memory > > compression, which changes the reclaim dynamics (and as a result, > > swap space size requirement). The problem is further exarcebated for > > users who rely on swap utilization (and exhaustion) as an OOM signal. > > So I thought about it again, this one seems not to be an issue. In > most cases, having a 1:1 virtual swap setup is enough, and very soon > the static overhead will be really trivial. There won't even be any > fragmentation issue either, since if the physical memory size is > identical to swap space, then you can always find a matching part. And > besides, dynamic growth of swap files is actually very doable and > useful, that will make physical swap files adjustable at runtime, so > users won't need to waste a swap type id to extend physical swap > space. The issue is address space separation. We don't want things inside the compressed pool to consume disk space; nor do we want entries that live on disk to take usable space away from the compressed pool. The regression reports are fair, thanks for highlighting those. And whether to make this optional is also a fair discussion. But some of the numbers comparisons really strike me as apples to oranges comparisons. It seems to miss the core issue this series is trying to address. > > * Another motivation is to simplify swapoff, which is both complicated > > and expensive in the current design, precisely because we are storing > > an encoding of the backend positional information in the page table, > > and thus requires a full page table walk to remove these references. > > The swapoff here is not really a clean swapoff, minor faults will > still be triggered afterwards, and metadata is not released. So this > new swapoff cannot really guarantee the same performance as the old > swapoff. That seems very academic to me. The goal is to relinquish disk space, and these patches make that a lot faster. Let's put it the other way round: if today we had a fast swapoff read sequence with lazy minor faults to resolve page tables, would we accept patches that implement the expensive try_to_unuse() scans and make it mandatory? Considering the worst-case runtime it can cause? I don't think so. We have this scan because the page table references are pointing to disk slots, and this is the only way to free them. > And on the other hand we can already just read everything > into the swap cache then ignore the page table walk with the older > design too, that's just not a clean swapoff. How can you relinquish the disk slot as long as the swp_entry_t is in circulation?