From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) (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 50DAD372673 for ; Thu, 17 Sep 2026 07:31:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789630298; cv=none; b=F9H23GgxkpB+EXm2z4wJiAm2mYZJgS5sbA2AxBrV3wk4y7ICzzt5Sw1Gy2MzaZBjijkHNkYu37nfn2ewmF4gZ+AsM+ROf76eEoeDINwQ2IHS/vXDx6F9TRTZ9oxCh7SzkPvf16ZpUweJVNkqIcHS0ZEpaz5aWDeaSjwy900Qmhw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789630298; c=relaxed/simple; bh=aalPA+YRmodnwncx7vuTjRQb/Aq0fSpOz9DM5u9UYQE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dk8jHfuA0iHlAQJqyS3kF2VmoPdqPn9gmmLTy2BqWGrrJHFdjdYaLwfNnDdbKnwHqu8mI+zNW2vCDV4ezgTrNZQTwLdmlPeTx8jVFYo2hgIoYCaO3vcI/FHqOZ7HCZ+xwHfY4Wbv3WY6wuYcjYQuauNpBhVUQeBKEKxmWt5Dv7A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Rfzwbpe8; arc=none smtp.client-ip=91.218.175.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Rfzwbpe8" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=aalPA+YRmodnwncx7vuTjRQb/Aq0fSpOz9DM5u9UYQE=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1789630293; v=1; x=1790235093; b=Rfzwbpe8yyVr9rj9qFOOkFMkU5Ub8czdj3NZdqoEMD32nh5ej9Yzkalix658YVMzO2Hy0mLW 1JopZ4l798pdinxvGgcRzqfl3plBPL+He5SqIUPJGbwgVGuyFn02JQQSXmurSe2CnvTwQviuKwE qEYm7+6lUhvsYYsA8nrAyq5o= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta11.migadu.com with ESMTPS id c1cd059ca47fcf9d; Thu, 17 Sep 2026 07:31:31 +0000 X-Mizu-Trace-ID: c1cd059ca47fcf9d X-Migadu-Flow: FLOW_OUT Date: Thu, 17 Sep 2026 15:31:23 +0800 From: Baoquan He To: Johannes Weiner Cc: Baoquan He , linux-mm@kvack.org, akpm@linux-foundation.org, chrisl@kernel.org, kasong@tencent.com, nphamcs@gmail.com, baohua@kernel.org, youngjun.park@lge.com, yosry@kernel.org, shikemeng@huaweicloud.com, chengming.zhou@linux.dev, david@kernel.org, linux-kernel@vger.kernel.org, kunwu.chan@gmail.com Subject: Re: [PATCH v3 00/14] mm, swap: extendable swap devices (xswap) Message-ID: References: <20260916101929.149106-1-hebaoquan@kylinos.cn> 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: On 09/16/26 at 12:45pm, Johannes Weiner wrote: > On Wed, Sep 16, 2026 at 06:19:07PM +0800, Baoquan He wrote: > > xswap is a swap device with no backing storage. Swapped-out pages live > > in zswap. Its cluster_info[] array lives in a VM_SPARSE vmalloc area, > > and the area is grown and shrunk on demand as swap usage changes. > > > > The problem being solved is the static size of compressed swap. Both > > zram and zswap need the size fixed in advance, and neither gives memory > > back when the workload shrinks. The solution should be a device whose > > size can scale up/down as per usage. xswap does that by mapping the > > metadata lazily instead of reserving it for the whole range. > > > > Design > > ------ > > - si->cluster_info[] stays a plain array. Access is still > > &si->cluster_info[offset / SWAPFILE_CLUSTER]: no per-access branch, no > > RCU discipline, no tear-down state machine, no NULL return. > > - Only an initial chunk is mapped at creation. The rest of the address > > space is reserved, not allocated, so an idle device costs nothing. > > - Growth is driven by allocation. When no free cluster is left and the > > address space has room, the next chunk is mapped and added to the free > > list. No userspace involvement. > > - Shrink is driven by frees. The free tail is scanned, and whole chunks > > are unmapped once the mapped range is at most half in use and several > > chunks can go. One chunk is left mapped as slack, so the next > > allocation does not map it straight back. A ceiling lowered below the > > mapped range skips the half-in-use rule and is enforced at once. > > If the swap maintainers prefer the VM_SPARSE route, I'm happy to defer > to them on that. > > However, from the cgroup and zswap camp, two stipulations that I > reasoned out in the other thread[1]: > > 1. You must not charge compression space as swap space to the cgroup. Hmm, I don't have a stance on this. However, isn't this an issue zswap/zram have been doing? It feels like an independent issue which should be done separately? > > 2. You must make the compression space large enough to be outside the > range where users can hit space limits before hitting memory limits. We may need a way to define 'large enough' at first. From my limited understanding, take zstd (the best compression ratio) as an exmaple, the ratio is about 30%, 2xRAM as si->max is enough. Unless we want to swap to the backing disk with huge content which is much much bigger than RAM when xswap is ful. I am wondering if there is a actual scenario and concrete number. I am not against a large enough si->max size, that's very easy to change in code, just one line of adjustment. Just a concrete number and reasonable description is needed. I think this can be done later with a separate patch with a convincing log if someone can provide? static int xswap_create(int prio) { ... ram = totalram_pages(); maxpages = min_t(unsigned long, ram * 2, swapfile_maximum_size); ... } > > That also means not allowing setups where this is possible. And the limit is only an optional knob. If the admin does not set it, the device grows to the full address space, so there is no space limit to hit at all. It already behaves the way you want by default. The knob is only for admins who want a ceiling, they can use it or not. I hope this would not be a problem for your use case. > > I'm fine with fixing the zeroed page flood issue separately, as > Kairui proposed. > > So if you're willing to fix the cgroup charging, and if you're willing > to drop the sizing interface for a statically sized space that is > sufficiently large, I think we can find common ground. Thanks for the input, I am open to discuss either of them further. > > [1] https://lore.kernel.org/linux-mm/aqLi6cIjD2wJwk0B@cmpxchg.org/ >