From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from abb.hmeau.com (abb.hmeau.com [180.181.231.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C2351F94A for ; Wed, 7 Jan 2026 05:26:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=180.181.231.80 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767763581; cv=none; b=bW7pP4ZrPSoBygHvHFZ0DYLUmQN6TbPWl/tjJ0ZzBktG8c1M9yf80XEXgOyRoo7C0NBFjX81l6yj2r0KnTIE2zVpXlOvUxHF/z8yFbi8rTFmXlfymOglbY0GbcyLDPN7E9i9aHr2daqDdTkJrCr52rGOWl3QZRIz6XKaXZRpd9Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767763581; c=relaxed/simple; bh=pM8HME72yF0p0C61SWLPO/oiVObiqWvR8VLxoI416Jg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mgTQu9M/06AJ8jrRjcSxm6Xs+dwviG8+CjVgXLAQug1wgJ7eEJQkFYWnDvoxUFLHNLhh4+nY+cR6Q5U32nx5pm72tJlNf1uWPk1A3/i+dR8RZt9VVNhYa/6mfSLcn+yEaOHJyWQ++JpK/wbnJV1CEeIJZy1I+HLXBC+bM95TrpI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au; spf=pass smtp.mailfrom=gondor.apana.org.au; dkim=pass (2048-bit key) header.d=gondor.apana.org.au header.i=@gondor.apana.org.au header.b=GJCRqXRT; arc=none smtp.client-ip=180.181.231.80 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gondor.apana.org.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gondor.apana.org.au header.i=@gondor.apana.org.au header.b="GJCRqXRT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gondor.apana.org.au; s=h01; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:cc:to:subject:message-id:date: from:content-type:reply-to; bh=An3OU9c40o4Pp3HahHmZO9Bx8vnl4b0LJZ7HTtnswDk=; b=GJCRqXRTvG2JqtjZt8AaHTfezhDpyFvN8tSVbrEWez7N79ujNdZXLZ9LCVFQZ0i7M57XlMnEvZI q1KHOAGYsZ312YiJ1Z73etYDinbXe+lUXD0DR98xAh4jl9HKnYT0CPmOx6MdDWw6tSEWn/km7QeWT WK+SCjY5nxlqXF6W8B9XIH6AJ349O4z3MwHrTEkZhtpBIBhkS6RwfZ0R3CjC9tq28X/QWqb3rj9cS deGUmvEqiy+A2d77Q/B/oXP+hpwbQV15tNmRDcbg7UBvmwJ6LgEEB471/VblvL3E/d8Ba+zaOtzHY Z4ngPhO6NZX8BBDiFauzyp+OyUz7eRusEOdg==; Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.96 #2 (Debian)) id 1vdM3K-00EqD1-0P; Wed, 07 Jan 2026 13:25:51 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Wed, 07 Jan 2026 13:25:50 +0800 Date: Wed, 7 Jan 2026 13:25:50 +0800 From: Herbert Xu To: Yosry Ahmed Cc: Sergey Senozhatsky , Andrew Morton , Nhat Pham , Minchan Kim , Johannes Weiner , Brian Geffon , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should consider other metrics Message-ID: References: <20260101013814.2312147-1-senozhatsky@chromium.org> <20260101013814.2312147-3-senozhatsky@chromium.org> <5p4iyah6zlrnxpbsis32c4m5lrjj3pq7xwcugq35d2entwfai2@n2r6y3ga2ie5> <7q5gqpfshnc3lfhzxughpks3fc2knw2delpm5io2oe54monydl@5isuxnjputjr> 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, Jan 06, 2026 at 04:24:45PM +0000, Yosry Ahmed wrote: > > Just to clarify, IIUC the SG support would mean that zram or zswap can > pass a non-contiguous SG-list to the crypto API, regardless of > compressor support. I assume that the crypto layer will either pass the > SG-list as-is to the compressor if it supports it, or copy it into > scratch space to be contiguous if needed. > > So zswap, for example, will get an SG list from zsmalloc and pass it > directly to the crypto API for decompression. Then the effort to add > support to compressors can be done separately. > > Did I get this right? Correct, you can already do that today with the scomp layer providing the fallback linearisation. Adding native SG support to LZO simply means removing the memcpy that scomp would otherwise have to do. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt