From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.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 58E542BE658 for ; Tue, 2 Dec 2025 17:02:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764694951; cv=none; b=nVcscTHkr2Vb4l1PdRztelAJibpMxLEFU6riD68mILk0N0DmS4b6H8cb1bs+gFzcJrq+8U2qGFAcFVYsqOnSbJoxPgNZcSlELsv+vWhUOGXx7pOMq0QAfDv535fgVJNPW8HzIUtJVGBbEcHAzgnv9p3QdVInrdsY6nSl9F7Dwn0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764694951; c=relaxed/simple; bh=Btn00cE9Lg6zNxa8Q5JEXf6RUvoByI3vg9V3/vGA6cU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n6VQCg9rJtlDUXoASVKoavTUWqYeE8Q/EtfN6yREFB7IGikw4NTi57vgrSYMtjYa6aqhAbVW8vKYttgkp/4gS8lOIGVv8TKcZWfFOQaLKTtCcoGLWyCNCyHRhyCWqKmN/lSbwDF5+ooNsV1eG+GAjY4LeB6bpAVfGHHT5fGf11g= 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=npy2xXGM; arc=none smtp.client-ip=209.85.222.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="npy2xXGM" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8b1f2fbaed7so512349285a.2 for ; Tue, 02 Dec 2025 09:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1764694948; x=1765299748; 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=H+OuyPHxCQDMrymswmmyDSF1luxCUexrH74veMbiNtA=; b=npy2xXGM5dVnINjEbKk4p1X7unlxs5osSBrRF4KIzz1Sg+PyHCWFROdDYbcstQShQA sCyuRrOYCINUNdj84x7XA0tG1dMWgo41Qq5t4GXBXPCwXU9lgYeG2mzmAsilh9LiSOGN lGwETysoe1h1n75zjmPeuKUSw2Pt9ZzQQP9AjaszmcscDfi/yf8DjUtxifbQsYROQYcg q3AOWeqmLcCFQZd9M/U7F9PO3bHxjUEkEhQ8V/pTrLB4STlBt7zJqjWxjkVhtSnNFJ3C YStzRv5oGVygxrY05vZE6TF8DxFTg14OmTUuRnyqrPS5X7OHCM/I0jrcs9GVq892tL0M zbfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764694948; x=1765299748; 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=H+OuyPHxCQDMrymswmmyDSF1luxCUexrH74veMbiNtA=; b=ruLo8fs90dFKB7R70vYWmmIk6Uz4X75fD8CfZeiMHCQ2VRYTOGw2szVpbqX3m9lWWa GWT7nzJ6mTfgdZJCI9BFMQrMd8BKiD+xYuXGSePHl5f9c/45zpQolc1TPbftpmlcXA0p Fne7f2GoXSxUJmZ91UDXIVCCnw0tBcB/DxB/Rise7K7XSAaZIxO2Doh5Lvz/8qTsVTmO giGqD/8y5D1gDV6t2sVrCxeUeQw3WUgKFq8LrVqW7j0RuLJi3BUehv2essIFygOtqVPy +ftxQzogXExdpbs2gfqiu6JNlcRGJlVzrs3VigCMKH1HEnn0XWswZfZx2wPsolW8T0Sl ZVTw== X-Forwarded-Encrypted: i=1; AJvYcCVcN4IDbVJSaNdPI3I5YhBrzmW6W0kUpL++ycOSOCH5mCi+xIiBSX6bZE/st9V8hYGhUBwxS1oWEMsES/s=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0PZpNcNmMfJZX6cFXrukxWnL7rBKXlDLRr4gurKcMQzbY0ejr JqDKpgPiCtI16R2vuPwPOo/U0RRB3fj7hGM6/nda9z6M2gfe2QSszxdBQFsEH2T/nDI= X-Gm-Gg: ASbGncvObjTDGzadBDFp/slE3oMLXgwvSxVl7gxuK4/4jL/0PeslDMl4qqHF1UqdT7O Uq3X8RJYvAXpPMJgOSqDy/qMApImecsw+GStDlYZSsHkS7rHaFFm1aYoD4DMx+1heVg8rAvriCc e6joiJq084sAnmKN7jqZsryhdMyNajQ9X7OZm64ib7o3N9xiWXsPLFN7p7Gcb8MhV64956YW7/o 18uTqaOO47eP+a2qZjfogBuE+C7eU+FQCWYi6AjgctkzaYmm/ffdHW+3y61LK5VF6kKokEKXGCH ES2122KU996p5Ow/q3Tm4ZbXnsnbuRNFePaQ49ddcMnqOWcCWT3BKxvPrSY9bKhob5epJi1dej/ 5EX46zQRKZsAg5dKPo8EI1f1aHX81cABdyns6iUQ+bpjS3ACbg7gw4ALbXN58KEhADcSJWnqa2r dg9fbELWGxGA== X-Google-Smtp-Source: AGHT+IGCVAZCypxPe+el89uDov8jVesjd8N5Zeup/G2N11S9vRlXKFnljDCNMJXe65zPvUxUNdUX/g== X-Received: by 2002:a05:620a:4509:b0:8b2:7679:4d2d with SMTP id af79cd13be357-8b5d2f29036mr4235885a.63.1764694947819; Tue, 02 Dec 2025 09:02:27 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b5299a69d1sm1105042185a.16.2025.12.02.09.02.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Dec 2025 09:02:26 -0800 (PST) Date: Tue, 2 Dec 2025 12:02:22 -0500 From: Johannes Weiner To: Kairui Song Cc: linux-mm@kvack.org, Chris Li , Nhat Pham , Rik van Riel , Andrew Morton , Kemeng Shi , Baoquan He , Barry Song , Yosry Ahmed , Chengming Zhou , YoungJun Park , linux-kernel@vger.kernel.org, pratmal@google.com, sweettea@google.com, gthelen@google.com, weixugc@google.com Subject: Re: [PATCH RFC] mm: ghost swapfile support for zswap Message-ID: <20251202170222.GD430226@cmpxchg.org> References: <20251125213126.GB135004@cmpxchg.org> <7665130c511e3cd00f83e8b14de2b78e08830887.camel@surriel.com> <7e44e8654eb0ed5e0f590b3d705b258772dadb57.camel@surriel.com> <20251201164338.GA430226@cmpxchg.org> 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: On Tue, Dec 02, 2025 at 03:49:22AM +0800, Kairui Song wrote: > From my perspective, Chris did co-developed, suggested, reviewed or > authored many of the implementation details around the swap-table > idea, and he implemented the swap cluster allocator in 6.11, which > unlocked a bunch of follow-on optimizations. > > I’ve been working on swap for a while as well and have rewritten and > refactored large parts of the swap, swap allocator and swap cache > (mm/swapfile.c, mm/swap_state.c, swap.h, swap_table.h). Maybe, yeah, > I’m not a kernel vet with decades of patches yet, but I do think I'm > familiar enough with swap. I think Chris' work, words or code, has > been looking good in the end results. I have absolute respect for your work. And if you say Chris was instrumental to getting it done, I will take your word for it. > It's hard to put a penthouse on a sandcastle, and maybe that's the > reason makes it hard to describe or layout the further implementations > of swap. Sure, I can understand that. However, I think the conflict is not necessarily about implementation strategy, it's about priorities. We have a usecase. We have a functional implementation that satisfies this usecase. It was sent as RFCs early on to gain consensus on the direction and find the best tradeoffs wrt other usecases. These RFC threads are the place to voice concerns and influence direction. Both Chris and you have stated that further swap table work *may* also enable this usecase. However, at this time, I think it's also fair to say that it's more of an afterthought, and no concrete design or code for how this would actually look like has been proposed. High-level ideas have been floated, but as you can see from Nhat, Rik's, Yosry's and my replies, they don't really meet the necessary requirements. This is not some principled stance. The virtual swap patches are difficult to develop, especially given the current rate of change of the underlying swap codebase. If anybody working on vswap had seen a plausible way to solve these issues through incremental swap table improvements they would have jumped on it a long time ago. It's more about priorities. Combining compression with disk swap is extremely powerful, because it dramatically reduces the worst aspects of both: it reduces the memory footprint of compression by shedding the coldest data to disk; it reduces the IO latencies and flash wear of disk swap through the writeback cache. In practice, this reduces *average event rates of the entire reclaim/paging/IO stack*. These are higher-order overhead savings that are difficult to beat with first-order descriptor and lookup cost optimizations. We obviously want to have both, but they are orthogonal goals. You can see how it doesn't make sense for us to deprioritize the former for the latter, or why Nhat says it's an apples to oranges comparison. It also won't work for one party to say "we will fix this, give us time". Everybody wants to advance the thing they primarily care about with the least amount of detours. That's where we have to find compromise. Either let people pursue what's most important to them, or lay out an encompassing design to build consensus and organize effort. And yes, let's please stay technical and on-topic in these discussions. Let's acknowledge we have interests that overlap, and interests that do not. Then find ways to service everybody's usecases. Disagreements are part of the game. There is no need to get personal, pull rank, or make accusations to dismiss somebody else's clearly stated usecase, perspective, or objections. The best way to avoid this is to make technical statements, and reply with technical responses where those statements are made.