From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (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 50A9B357CFA for ; Wed, 5 Aug 2026 14:18:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785939485; cv=none; b=H1V4gKHoygPuFndsLGqKk0rdziXXVhmIc8k/OW14GiFTKSmupp+/qgonYXlK3P2E2VjhSuVenxBw043u+TnXKUvDP0QmUiVB/5sxMnE5spy76nmms3RKMXP6yjkjj4TGAKB0IhpQE1kJ1VNxWoAmj2w+gJiNGHk2bXfj0Jr0FN0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785939485; c=relaxed/simple; bh=dMm91h9xxDvCvgfGEohBgsT1DXYgAEVC389KV/921DE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YWzI9fIEX7IZ2O+SIGCwJD7OG/qlwEYJ/IINEal/5wFL8Bh4x5cigKxFA8Db4d0dEhx/jt2LA8S95bxCZKTO+wKOvNBm/X1xDiMZCJlqQwEoiQIJb3nDEiwUTsEBOevb160KrgmEEzTch9Ai33YgtXAU1pRZEFWLk875k26Dq7o= 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=kje2W+EB; arc=none smtp.client-ip=209.85.219.54 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="kje2W+EB" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-8f29ec73064so6854466d6.1 for ; Wed, 05 Aug 2026 07:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1785939481; x=1786544281; darn=vger.kernel.org; h=in-reply-to: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=s24Ux4wjwBAvtoHR2FA95iIi79nffodZBBurUTUJ1jE=; b=kje2W+EBSR44zBpITLWnvzkRQfMXLKgQOH94kbJhaVBHdE+QIELWirc3gMb2gXuqro DsyyJeMbhSjskzz2f3ea7fyCTZFq+vp0W9odWUMEjrTs2rX26TqZ/66xh29WbuF9zDRq zsWV64rCcBtZEEG1mpM3pwkP92OTJyLMEr7L1ew4u7nEHMcPPBzB4hIHbJ8c9PrJ1+SC dFZVfF+HvqZX1mNImslP0uw09ZsfPjp6QSAs7vqfttKEzMnsDy53ActsLCIlWx5KsD1G QPZcH7nKf023KddBfrlwP7KtT7w904jvTgh093jieSQSudBpy30NUxX2WDu+3WTnOa5x yiPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785939481; x=1786544281; h=in-reply-to: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=s24Ux4wjwBAvtoHR2FA95iIi79nffodZBBurUTUJ1jE=; b=kZIhmMcNgTaPeN1jseUZJgL5I3w/35P81JrjUm/Xyrlh+9+kZXlAVRxLPbErFssiw2 m48S7N+ATul35bwR5aptS3Rzm794HE4xrjwHbHFIzdBpg2Y77KQHUnn0c4GTdzszg2WQ QKyUz/MQFIBx9fJS6jStrZynkIRYRajATF31f7rzMnLkkC1cxaGccJU1Rr1QdaA9zyHE WgeQq+uNJdZ0ym2ATyfBAGVck8jVbaHP+DlsTf6Xuzi0xGJdt92jp+5aVUrJCeY5loFg 6sLTsCRjoRJhaoUuz7iPfQOAGdXkkJmX5FVZFHssSLIUWIvVHMWQmSGvmaWcqwmFACGL hnWA== X-Forwarded-Encrypted: i=1; AHgh+Ro8xCq8HD+7YQj45Vurfx/GkoUv7i4Syt9/kjOwQGEa50Ntgo+VJtMXy/TCifzlWDJ6r+N5ZWytTyfcTG8=@vger.kernel.org X-Gm-Message-State: AOJu0YxkkePWaHVi43jUarjKrAywNy4NE8j0L7iGsGPdua6Z8du1uqeV PH2YkSVVjQ/dJle0MwO5vQpO10+qobRVp+/Gn6c90VZfFTaV3S4Wd9Lu/G4MBtJl52Y= X-Gm-Gg: AR+sD10F/ED0LHPvbJh2+IkbcbaqvvoyxUZT7SZhcC8xnCnWBm4M08n4KqLuUm2RMG1 meMIfvrvpJDjDahviBPPkf2VHIeqNIEz37mFw4jLQ1LbjEgpCbr3Oimno236pbM7ubGng5XLX3J yQW5Xz9HmgMEEKd/214g9GRCq8L2HNddiiCo997oD1D7Mo6YwD7GtnSl8VOaBTaKhNOC+yPI+IQ EeYez+Uthnrqye6NxtsE67A3tVGBErZPPtYmx9sMLgJdz6NXuJhyWl1MXYrrQRu4ATiaxOOTv6O UpSHeUbTvPa0a90tocyz5C4xkFN3gkTRiW7gO4Hoijk243T9qgGErctn4RGibum7OJsl6Y3TGXQ NWe7KZwlzZmFM9JyMeaKlgk9uAlmlx7T1F/LmEzUODI0ufnyndaqjIfzVUQnmaTNRAA/8Aic0ca k6p4cG8ufztbgYrCNDjc80SsgZwJtMXaVZ/yp77SnSt0BvdQo1vmJMynLCGeE= X-Received: by 2002:ad4:4eeb:0:b0:908:7fce:f111 with SMTP id 6a1803df08f44-90881098aecmr79986046d6.6.1785939480863; Wed, 05 Aug 2026 07:18:00 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-9087ff9d814sm26202096d6.10.2026.08.05.07.17.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 07:17:59 -0700 (PDT) Date: Wed, 5 Aug 2026 10:17:55 -0400 From: Johannes Weiner To: Baoquan He Cc: linux-mm@kvack.org, chrisl@kernel.org, nphamcs@gmail.com, kasong@tencent.com, baohua@kernel.org, youngjun.park@lge.com, yosry@kernel.org, david@kernel.org, shikemeng@huaweicloud.com, chengming.zhou@linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 01/10] mm: xswap support for zswap Message-ID: References: <20260805075336.3579395-1-baoquan.he@linux.dev> <20260805075336.3579395-2-baoquan.he@linux.dev> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260805075336.3579395-2-baoquan.he@linux.dev> On Wed, Aug 05, 2026 at 03:53:24PM +0800, Baoquan He wrote: > From: Chris Li > > Introduce extendable (virtual) swap device support ??? xswap. > > The current zswap requires a backing swapfile. The swap slot used > by zswap is not able to be used by the swapfile, wasting swapfile > space. > > An xswap device is a swapfile that only contains the swap header, > with the header indicating the size of the virtual swap space. There > is no swap data section, therefore no waste of swapfile space. Any > write to an xswap device will fail. To prevent accidental read or > write, bdev of swap_info_struct is set to NULL. Xswap devices set > the SSD flag because there is no rotational disk access when using > zswap. > > Zswap writeback is disabled if all swapfiles in the system are > xswap devices (tracked via nr_real_swapfiles). > > How to create an xswap device: > touch swap.1G > truncate -s 1G swap.1G > mkswap swap.1G > dd if=swap.1G of=xswap.1G bs=4096 count=1 > # xswap.1G is 4K on disk but reports 1G capacity > swapon xswap.1G Sigh. Why does the user have to go through this dance? Why does the user have to decide in advance what size the space needs to be? You point out no inherent limit to how much can be compressed, so there is no reason to make userspace decide on an arbitrary one. There is no reason to tie an address space that can be managed transparently inside the kernel to TWO named files on disk. There are plenty of past discussions on this very topic. I don't see the point in resubmitting the same thing under different names, without even a reference to previous discussions. As a side note: if you have to add "(virtual)" after every instance of "extendable", then maybe "extendable" is a terrible name and you should just call it "virtual".