From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (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 AB8683C6A52 for ; Tue, 3 Mar 2026 16:59:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772557154; cv=none; b=X/1GnFojrUUpWI9cKyuLJqJuuRMqniJW+5bQAmT3y2Jywd9BGkAJn8TsR/pUtEphzhH5AM3CiUy74DlEjKO1VjJyI7yqzP7FYcyRiHo89Qy3pOhepzC0AitaJMjrn3SgkGHdd/GPGN74hb+Uux6swvW2piF1xbrYFYKfZQUcSAM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772557154; c=relaxed/simple; bh=Vv8oBh6u29fah7cqUz/BRbt9XhR+uNSS5yLEIDzcwhU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ohf+e7CV7M4ZRMDsqyXm4eAWZmUF5xL/mDx2UaGjDA2wi266MtE+fvrw/dckjXaCJ/cx0nMjIjWy/okP227qBf86uGgIaWul0B8lE0h+zKBDg8rW3qf7gYm3rQPbpE2LXXathYm54xSRS0v7Ezk9upMZk03V8x6nxV4iKEm7CLQ= 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=Y0rgovww; arc=none smtp.client-ip=209.85.222.179 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="Y0rgovww" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-8cb49f63238so321290985a.0 for ; Tue, 03 Mar 2026 08:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1772557151; x=1773161951; 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=6FEv90vReHYT0L9srNroqmwLlfOuALvxi8SW9QHvPXM=; b=Y0rgovwwKIbT6GfHwNbuTWGqZYkSHyDjsJIit1KFsls01XWCgbxyor7/MKd/FVUKK0 EnrGrkYkCLvD8Crcb92LhQq3s7A8N/wc6Pm/LvrkoX+2ZRmSHuAtNsLEAzeatqHp3+44 3lOJRak1eRZ4AS/NOgYBNawTxpNI4dRAmsJDPKATbA2d1dgRScXBjexkocX0wtS6GK1/ PKukcuX/N3Il29DODhhbZ4N+1dq+SKTdsopK97Ke9aCgln73eWwjz6qROw7p9luZqENM dq+da8FYuc0Sk3ph7a98IHtt+h02OK1simO7TRVi/vwi0glxNepDM1lfD7J+UeVagM6k 5rNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772557151; x=1773161951; 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=6FEv90vReHYT0L9srNroqmwLlfOuALvxi8SW9QHvPXM=; b=t4VLlzjn9sANau6hv8ckQKQPaDUa6zKYHDGVBP1BUGeLrMkRYOy1ErExzxRGQlO3On 4l8Sd2syvs81XVFG8pW8IANhgg3HXrVJnrRfMRRu2N3WDw+Z+Os61gEAsTBPFoIz+rvZ HxKiyo6SBB/biZX8EyObmH47HoliURBw3X0KEapExAo0f2swaTZU8Fp55qfPF9KWkNpF YnDXG5avr4Kin3YNASZof8p1cH0oQyvy4kpy6n0qMqGDpSMnbxMobG+MNZNK3DuyZZ7y K2qMIQ+hKdNiMmcth1oo18jsOr7jxbji8rEBC1BxWB/JQ/V530IXOmJ46vkRtvLJMjr3 E+8g== X-Forwarded-Encrypted: i=1; AJvYcCXTnY2ElmNvYWqIz1R90FS5c8BvTAlkpOyXQb53gCJNSpaYXkrKL8wfldyBzBWpfictEeG5qyTx7FcaJlM=@vger.kernel.org X-Gm-Message-State: AOJu0YyWdcjc5jZ4nRMNZyFBHuafAr7111rIMmFGhtoZ4WFPrVsLvN9s rTy1O0/OdtTkFW+e6vlQXfzCEoMBLQ3MGHkppTz1zjqm1XrCzXjFQXNGAhvNIb28EWs= X-Gm-Gg: ATEYQzydPsg0RJmHZZbsVslmPF7j/ghC2RXt0uufd3e//ez5apHKn9oPSwOmkVDdKs2 gPAIyGQx129LbPD21FBp826jT6Zc30B+b2Y3zXHirN+ndId8sR9avbQ1w97ou25gPK7ptw8ArI7 LYWcY3V4F/ZdIaa+piRR027qz4Nv1k8287wvg7jdAbWjmbKxa7okFMqcPuYfqVPPTFuJzBQgnYh FuDb1lsOvNtKsnqoG9+XgSCG9yvPz3bls8zcbRdT/WsoZU4t0uP8vcaTUgsa2aUJKnUpJbMGVld Y5XBbPEqX5OSCLfAWduAuTghJRocnbo7sLJPPUO3jvaAmR18ju/eDkQ2ja7YzOs2o1h6JV7JtGJ w//zxBZ7IS8G+FEbtHS32OpgHrT+5Be1zWmAb2kkrejgOXt3qTAc9s7jMrUGjplAYhMrjw+Z48i lWjqr6uW0DGGAx8OEPq8FYi7Y+4/oZ2A3Y X-Received: by 2002:a05:620a:3707:b0:8b2:6606:edaf with SMTP id af79cd13be357-8cbc8f16224mr2082525085a.37.1772557151379; Tue, 03 Mar 2026 08:59:11 -0800 (PST) Received: from localhost ([2603:7000:c00:3a00:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cbbf7161fcsm1414410985a.33.2026.03.03.08.59.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 08:59:10 -0800 (PST) Date: Tue, 3 Mar 2026 11:59:07 -0500 From: Johannes Weiner To: Christoph Hellwig Cc: Matt Fleming , Andrew Morton , Jens Axboe , Minchan Kim , Sergey Senozhatsky , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@cloudflare.com, Matt Fleming Subject: Re: [RFC PATCH 1/1] mm: Reduce direct reclaim stalls with RAM-backed swap Message-ID: References: <20260303115358.1323188-1-matt@readmodwrite.com> <20260303115358.1323188-2-matt@readmodwrite.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: On Tue, Mar 03, 2026 at 06:10:07AM -0800, Christoph Hellwig wrote: > No way. Stop adding hacks to the block layer just because you're > abusing a block driver for compressed swap. Please everyone direct > their enegery to pluggable zwap backends and backing store less zswap > now instead of making the zram mess even worse. +1 The virtual block device idea seems simple and attractive at first because, hey it looks just like any other swap device, and the block surface is so much smaller than the MM surface. But compression is a *memory* consumer. A big one. And with swap it sits in the reclaim path. So now you have to solve intricate MM problems with the block layer in between. The effectiveness of compression as a reclaim strategy is also highly variable and dependent on page contents, so the static properties of the block device abstraction are a poor fit for the problem space. I'd propose the following: What keeps users in the zram camp is disk-less setups. What keeps users in the zswap camp is reclaim-writeback, cgroup accounting & control, and the prospect of fully dynamic sizing. There are ongoing efforts to solve zswap's disk requirement and with it its dependency on static address spacing. The gap on the zram side looks wider, and more awkward to solve given the block layer intermediary. And it's already 2.6x the SLOC of zswap. So I fully agree. We should try to make zswap the single compressed swap implementation. It would simplify things dramatically for kernel developers working on MM and the swap subsystem. It would make things better for users too.