From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.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 1AD5C315D3E for ; Mon, 23 Feb 2026 16:52:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771865548; cv=none; b=bWDtOWJpBGuB+XJPcU45k5/Sfa7ciaglVxM8LS8yF3pBaGUZZF5hs68p4gmJGXesmM5xTPkHLJBfp5cjT3gl25XOro8jk3V2VjyG+Hr1wnbwSzKC4tIe2Eco2exN3isEDfoIylZu3aYrHFeEL0xnOU8RDd5cMx8q1LeO2LVmnFM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771865548; c=relaxed/simple; bh=bx3iOV2ugLkpdJZcrJoQAabRqUf12TYssE63qknpYWs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HwTIyhqGNLaykEwzbaLFz76yvmZw2Czs8n8BFNFNMo7t+Oa9AJq6xIk0L1DKUVu3Pu11zDFBQBlnorGNld4Fx2VvjEocHnGBboN78XrS83UdkfiGHDzRYGw3JPw3HdB3sgIXr29w8SMQapiKhyJ0yYnSPJwYy7exRUEUlDRnzsk= 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=MwyrwpKj; arc=none smtp.client-ip=209.85.160.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="MwyrwpKj" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-5069df1d711so42277231cf.2 for ; Mon, 23 Feb 2026 08:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1771865545; x=1772470345; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9p76BczVPf+ipMBZjWxZMf67W68G0E63s5eoAZ2wq80=; b=MwyrwpKjTdGFMtlIkDgFe4CxRoHf4akYRISDvmQPogMk4uSdA6gfs/AQiUF8pgkpCG 1vUsb/ojyoQl5N6b2t9ngti5es99Zaq+MavSe/sBmLZDMj6DNWMkZ0Wt7BfGnpHwRRhA woI/RHrqNMMlgTrTkLssXA58M0IYm566Db2/8yU9tzS4ZFCmNI2A3/jQZFeXcYfKzAcV 4IncVJqUihnnNyWiiWOY5YxGaqzUqYtxWh/cpTpbuJz2DoAsMYEhfjAQfLoMUg6InhX9 seczxcxkbeEaH8Y1Hy2Ab6DTrrEm0FM14cH3n7fZcwFFcXIVjD85V8EFCKe0GKfz2MwW f55A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771865545; x=1772470345; h=in-reply-to: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=9p76BczVPf+ipMBZjWxZMf67W68G0E63s5eoAZ2wq80=; b=knDDNBHSZI1kanx2mWGVLfQSreP8seTO2/PfGaht/Yc1uDFzwGxwjoL85E0mdDzYU8 7onFBsFKsk+2xuEyNjByhULxQ9GauBoS4R6UlBSGSIpUOTUYkrZNMOFx6jPQUX6ZfH+b vH377ZAUMoIqaRF5y5tgWcqHdAK19TGOJ65G5yJqABTvd+FOqCD0Gw2rxkdTPoeYvsJ8 tXQ/dDY8n/2B2AXIsKMuut1vNAwrsE4XGwUnwXCNtDbb5gd93Okj4nyreveWQD7pYUvg cWkQl+xf+/NXS3YVfH9xqpdvXq3gKua6X4vFoBUqguI4m0Hf7eFqYAu6A+M/MR5Yhl+w Pfzg== X-Forwarded-Encrypted: i=1; AJvYcCVZ0HI92MeK0XCgFXfTehrP8O2JaqSYk9xid70SvbAwHjZfOVvMoBRZ6DshMWd8FGLFFfTHuV2j4lBu++8=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1bRbJulMetmquPwifaXr/JGaw3p+vDllLuXhpwmvQEdR/Do97 89TbR1u7OoSlBphX12SFB3nGzmeDw3stRHgu/ks+HqT3NdvTmQXCGRlBA9dIX9j+arI= X-Gm-Gg: AZuq6aKI9tUZrlZweawEWt0iu1LJZkDrAmTc6GTRtff27Achor3DwkdxL7bYjf7h8Ms dJQkY82Pm7uyCKnoYEo+JVdVQCo87cvXanb6u6BduO0VDtg8TPlj11SNvZ9FRJ6NGVNO/VMrhjT ANf3ooORN/wdmrGDI7sM7RMjWfemmjzXSMwxKp7AL0KTj+wVVypnbIvj70SrmcLzpKsj/txY7Qf 7+YxJ0B5aTK5zn62CPNrHw4cc02Jje7o6pUvu5rgKMo/W61WKaJUUA88AUw55nbE9zl6AuZ0ZwL uXiwJJyOFUCZ+0P5avSBC0SXZMFx0PM0tZRX+RMuByrbXeWhVwJKb6gjNLjlL/PjyWrqzQ7j1ay abld6ZRQYtqw4qXFpUYVDCKOKYiHkLJDDrRiTtc42c0kL/QSunVn/WyZl2JpOuP4TAwrkmrl2JA JaBhirQyKZ339cspo2CEdr7g== X-Received: by 2002:a05:622a:11ce:b0:501:4859:c7aa with SMTP id d75a77b69052e-5070bbab6a2mr133092191cf.20.1771865544833; Mon, 23 Feb 2026 08:52:24 -0800 (PST) Received: from localhost ([2603:7000:c00:3a00:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5072afdef0bsm4637311cf.16.2026.02.23.08.52.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 08:52:24 -0800 (PST) Date: Mon, 23 Feb 2026 11:52:20 -0500 From: Johannes Weiner To: Kairui Song via B4 Relay Cc: linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Zi Yan , Baolin Wang , Barry Song , Hugh Dickins , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Yosry Ahmed , Youngjun Park , Chengming Zhou , Roman Gushchin , Shakeel Butt , Muchun Song , Qi Zheng , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Kairui Song Subject: Re: [PATCH RFC 00/15] mm, swap: swap table phase IV with dynamic ghost swapfile Message-ID: References: <20260220-swap-table-p4-v1-0-104795d19815@tencent.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=us-ascii Content-Disposition: inline In-Reply-To: <20260220-swap-table-p4-v1-0-104795d19815@tencent.com> On Fri, Feb 20, 2026 at 07:42:01AM +0800, Kairui Song via B4 Relay wrote: > - 8 bytes per slot memory usage, when using only plain swap. > - And the memory usage can be reduced to 3 or only 1 byte. > - 16 bytes per slot memory usage, when using ghost / virtual zswap. > - Zswap can just use ci_dyn->virtual_table to free up it's content > completely. > - And the memory usage can be reduced to 11 or 8 bytes using the same > code above. > - 24 bytes only if including reverse mapping is in use. That seems to tie us pretty permanently to duplicate metadata. For every page that was written to disk through zswap, we have an entry in the ghost swapfile, and an entry in the backend swapfile, no? > - Minimal code review or maintenance burden. All layers are using the exact > same infrastructure for metadata / allocation / synchronization, making > all API and conventions consistent and easy to maintain. > - Writeback, migration and compaction are easily supportable since both > reverse mapping and reallocation are prepared. We just need a > folio_realloc_swap to allocate new entries for the existing entry, and > fill the swap table with a reserve map entry. > - Fast swapoff: Just read into ghost / virtual swap cache. Can we get this for disk swap as well? ;) Zswap swapoff is already fairly fast, albeit CPU intense. It's the scattered IO that makes swapoff on disks so terrible. > The size of the swapfile (si->max) is now just a number, which could be > changeable at runtime if we have a proper idea how to expose that and > might need some audit of a few remaining users. But right now, we can > already easily have a huge swap device with no overhead, for example: > > free -m > total used free shared buff/cache available > Mem: 1465 250 927 1 356 1215 > Swap: 15269887 0 15269887 I'm not a fan of this. This makes free(1) output kind of useless, and very misleading. The swap space presented here has nothing to do with actual swap capacity, and the actual disk swap capacity is obscured. And how would a user choose this size? How would a distribution? The only limit is compression ratio, and you don't know this in advance. This restriction seems pretty arbitrary and avoidable. There is no good technical reason to present this in any sort of static fashion.