From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (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 091BE224F3 for ; Wed, 7 Jan 2026 05:39:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767764397; cv=none; b=Wa/ERtQ1je56B6J38NyD+t68tNDm5FCq2w5Z/33+PhvRaDbU4unJHgxxojklZlTy20hdHisJPnGtufPHkFwu9T3WxDqsHAX4UItZymLfy/cDPX+N8ue1HZjM8sXEAzV3y/hIq3DueeZ/OsNzksQY5L2qV31eglZIFbR7gVMJyac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767764397; c=relaxed/simple; bh=SBkryntgSdtTv7kbj1jjsyYNl9nbf/KsI4w4Xyr396E=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=cIx+lFN6GV/0lEj4yi8lcVS/oDdI5Mi4uLwln6UjYWkoarJwPJQbsk/ugfT0MJa2NCF6LIih+2X1yEVm2EnydAlGpCEaZwIR0qcvk/zlv4H4JvTa/+5XWYXFrDHysoPEFTJD6plqSjrEv4+ZLKowE16H5SVm3rC1YynB56tjgl4= 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=X809OQYx; arc=none smtp.client-ip=91.218.175.179 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="X809OQYx" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1767764392; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EO7QxiUX2cfRPRoeNoYBjPawt4DwoH+tri6kf2FLhqo=; b=X809OQYxpxEtJBMzt9bxtE2GdVBcxsJeMUlsgsno7J8+5jGdHcVZA3JTm9kyHH1j6LJHnh HtCnpz6EqlZtR1wwzqW8LJSOh0XReIoY0F9Oa0xtM508cMi4W19Y409dqPmepQ14/0cD8K 1FeEE88QoIwgL114di7k7jORkgjoOzY= Date: Wed, 07 Jan 2026 05:39:50 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Yosry Ahmed" Message-ID: <9b7d6e6292c64f21b8d09def1b6723f02faffe88@linux.dev> TLS-Required: No Subject: Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should consider other metrics To: "Herbert Xu" Cc: "Sergey Senozhatsky" , "Andrew Morton" , "Nhat Pham" , "Minchan Kim" , "Johannes Weiner" , "Brian Geffon" , linux-kernel@vger.kernel.org, linux-mm@kvack.org In-Reply-To: References: <20260101013814.2312147-1-senozhatsky@chromium.org> <20260101013814.2312147-3-senozhatsky@chromium.org> <5p4iyah6zlrnxpbsis32c4m5lrjj3pq7xwcugq35d2entwfai2@n2r6y3ga2ie5> <7q5gqpfshnc3lfhzxughpks3fc2knw2delpm5io2oe54monydl@5isuxnjputjr> X-Migadu-Flow: FLOW_OUT January 6, 2026 at 9:25 PM, "Herbert Xu" wr= ote: >=20 >=20On Tue, Jan 06, 2026 at 04:24:45PM +0000, Yosry Ahmed wrote: >=20 >=20>=20 >=20> 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. > >=20 >=20> 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. > >=20=20 >=20> Did I get this right? > >=20 >=20Correct, you can already do that today with the scomp layer providing > the fallback linearisation. In this case I think we can just make zsmalloc return an SG list and use = it in both zswap and zram. We will fallback to the memcpy() in scomp inst= ead of the memcpy() in zsmalloc, and we'll drop the memcpy() logic in zsw= ap as a bonus. Will this for acomp though? >=20 >=20Adding native SG support to LZO simply means removing the memcpy that > scomp would otherwise have to do. Yeah the effort to add native support to compressors can be done separate= ly. For zswap, I think the most common compressors are actually zstd and = LZ4. >=20 >=20Cheers, > --=20 >=20Email: Herbert Xu <> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt >