From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 7225B23C4FA for ; Mon, 24 Nov 2025 17:27:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764005245; cv=none; b=Lw0xmUB4FTASzUcFuk9ASc68K5Sws/LaMldNIoyKFQ4i4g5tLOGCAC1eZQSopnWuGCyCZzSDwhU+rSc+TEPx2g+1oVipa5hbV8RJHb3uUT5WEeQopZQyE1K2XKYxB2LEAyDyfmc7gy/ZxSJoIfqRxXoLcfxxBavdviZMdNt1QUs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764005245; c=relaxed/simple; bh=Jh9JeIulv+oy14LpUfKF5pzLLdMb/bky1p7TI9+5obE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GCTTwAPAb2+cVaOmPDtnlrfoiFjRk/K0EiZ4kHbCeFKJwrhDsurAQGI3Mxp6p4eoNRG5YICcCOvxnqqjcL4+TZTW+CE4CxRSJDsGimWag/WTownl8lkbcgNANzB6o7O/zZdPWjawL0X2Lt4lEEacudi7f2/FT6eUUyzYWtGI0yM= 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=RyWcy8rI; arc=none smtp.client-ip=209.85.222.177 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="RyWcy8rI" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8b1bfd4b3deso370872385a.2 for ; Mon, 24 Nov 2025 09:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1764005242; x=1764610042; 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=53HUP+p18ROArguaOr5CiVNJvWgLYFuwy860PsL/bOU=; b=RyWcy8rIdI+om7jaPtYJxXbmR9ozYKXekAFWmDc1v4/2pR950wuPmyaoPI9Mtxo+Bf 9CSa0DZ/IIfr8ShUUALu9LUp6h9sIffWIGFgre9W4HQ25Ikx9fa6RHPiZxnTZRasW99B 3bGh/myB9O3FQ3piu2VY6EAJxyMCSeBokXp7rxC0Kx//z62k/g9O/oT2PgOmZma+lYaR EwxWp06byovSMSsGYRqcHhqYj4roZrXQVnN+9iOvUOcH/fvdE+QKxFsHvfgIEbVEYEvi c34WpbFXxLan6+f6TaFULZxmYzCCQj+tUxt0o654ur5+O8TqFmceIJ/QyIleBYCiU/Ke mR/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764005242; x=1764610042; 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=53HUP+p18ROArguaOr5CiVNJvWgLYFuwy860PsL/bOU=; b=f8e+XZIkrnLjbFWtpH/ahbnxPXOb/lR5cG9LkW/yXcdGIAr/Rev3BCCeRDhV81zDP3 juhj2MCyeUjSJN4XhgSSV90ftwyYdEWEnbz4ZpwUOOtFKYgqGxON7fQAFUZV1YNWFk6S ROZJ02TtVPnrpH8pVO1wi0IuqdH8fiO5/TCpLL4K2vNjHv5zPZV42tI09AdVWtootfPA +WkmYGHfHpnkxiclzFMWTAi67b7LOm7YAf4Y2M06ZSgzAxEzKLXN0yM2sSmv7OFp/jFl SyNU7eEu2SmFCehGjFXybKfyjZBEOtTtThv1hOLjX+DEqRuErX261RDtzvErvasZRtlh datQ== X-Forwarded-Encrypted: i=1; AJvYcCVABbGzi2jKVmRN1ZS9hX7rFZYf7p658gctSdSwXYPq6SzZGiFmqjsUoeRoqyJbXtl1caHl8QP+tqFg7N0=@vger.kernel.org X-Gm-Message-State: AOJu0YyojusiVd+0guOvF0w/tlKmpCOUUSjM+8ogywmzRaIN8UDqz4s7 r6K3yQaj3fUTCfMXujsomi/mmi4mUgIa76IRXUniVsxKmUdrHV0cmrMUNKzEZeQOemM= X-Gm-Gg: ASbGncspo1ctrbc6caw+Z/flaTZs6Dwc4gGFbCARJVAEnUxNYNIBF3PceYzIdMAy+1Q 9u+AtEIEaDSfiAYoFrcynIIqtnRtHwDC7geo81o/eYjdXMEzjnGjZkVMoLD/ztSxgB6M/nijAvQ Cy+qPfan9ml33BmNEl8D/hmTzICHHpaYL8dB9d1qwhiVSzXe1Wj6YHU2WuTQvlBfJwMA4ndNi6X o8S0a+wxisaohX3L8c+E6zv7ZsmNb9H5bp1c5HFYVNJEvpI1UVPGZg3mYeFaNggpqq5a27UzrXj 5Pk95797j7ehd8Fuj/2g8KLpwBddcyDG/yKdfKc/ujHkQZtgQ1Rmtzio37bQfqXxAe6o8Oa2tGD US4OGOGBjqMr5n/zbnXD5R8Whc+W+Suqp+mU0TfnGo8PM4b/AQKZzVvnYzs7H57q+d/MJ8RMfLW HKaQXnuG0Vz/8m5tWDuRKN X-Google-Smtp-Source: AGHT+IHKduITjRZgFsxf3yZBdRQa7pPuvh/WM8xvhhS2h8K5RQK3iDkeKzriK0L3X6SSLeXOlUtobA== X-Received: by 2002:a05:620a:3728:b0:85b:cd94:71fe with SMTP id af79cd13be357-8b33d1d1146mr1383638485a.33.1764005241928; Mon, 24 Nov 2025 09:27:21 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:e601:6a28:ae2e:9b22]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b3295f2f6dsm987992585a.54.2025.11.24.09.27.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Nov 2025 09:27:21 -0800 (PST) Date: Mon, 24 Nov 2025 12:27:17 -0500 From: Johannes Weiner To: Chris Li Cc: Andrew Morton , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Yosry Ahmed , Chengming Zhou , linux-mm@kvack.org, 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: <20251124172717.GA476776@cmpxchg.org> References: <20251121-ghost-v1-1-cfc0efcf3855@kernel.org> <20251121114011.GA71307@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 Fri, Nov 21, 2025 at 05:52:09PM -0800, Chris Li wrote: > On Fri, Nov 21, 2025 at 3:40 AM Johannes Weiner wrote: > > > > On Fri, Nov 21, 2025 at 01:31:43AM -0800, Chris Li wrote: > > > The current zswap requires a backing swapfile. The swap slot used > > > by zswap is not able to be used by the swapfile. That waste swapfile > > > space. > > > > > > The ghost swapfile is a swapfile that only contains the swapfile header > > > for zswap. The swapfile header indicate the size of the swapfile. There > > > is no swap data section in the ghost swapfile, therefore, no waste of > > > swapfile space. As such, any write to a ghost swapfile will fail. To > > > prevents accidental read or write of ghost swapfile, bdev of > > > swap_info_struct is set to NULL. Ghost swapfile will also set the SSD > > > flag because there is no rotation disk access when using zswap. > > > > Zswap is primarily a compressed cache for real swap on secondary > > storage. It's indeed quite important that entries currently in zswap > > don't occupy disk slots; but for a solution to this to be acceptable, > > it has to work with the primary usecase and support disk writeback. > > Well, my plan is to support the writeback via swap.tiers. Do you have a link to that proposal? My understanding of swap tiers was about grouping different swapfiles and assigning them to cgroups. The issue with writeback is relocating the data that a swp_entry_t page table refers to - without having to find and update all the possible page tables. I'm not sure how swap.tiers solve this problem. > > This direction is a dead-end. Please take a look at Nhat's swap > > virtualization patches. They decouple zswap from disk geometry, while > > still supporting writeback to an actual backend file. > > Yes, there are many ways to decouple zswap from disk geometry, my swap > table + swap.tiers design can do that as well. I have concerns about > swap virtualization in the aspect of adding another layer of memory > overhead addition per swap entry and CPU overhead of extra xarray > lookup. I believe my approach is technically superior and cleaner. > Both faster and cleaner. Basically swap.tiers + VFS like swap read > write page ops. I will let Nhat clarify the performance and memory > overhead side of the swap virtualization. I'm happy to discuss it. But keep in mind that the swap virtualization idea is a collaborative product of quite a few people with an extensive combined upstream record. Quite a bit of thought has gone into balancing static vs runtime costs of that proposal. So you'll forgive me if I'm a bit skeptical of the somewhat grandiose claims of one person that is new to upstream development. As to your specific points - we use xarray lookups in the page cache fast path. It's a bold claim to say this would be too much overhead during swapins. Two, it's not clear to me how you want to make writeback efficient *without* any sort of swap entry redirection. Walking all relevant page tables is expensive; and you have to be able to find them first. If you're talking about a redirection array as opposed to a tree - static sizing of the compressed space is also a no-go. Zswap utilization varies *widely* between workloads and different workload combinations. Further, zswap consumes the same fungible resource as uncompressed memory - there is really no excuse to burden users with static sizing questions about this pool.