From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A612E77188 for ; Mon, 6 Jan 2025 23:24:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53E0D6B00A1; Mon, 6 Jan 2025 18:24:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4ED776B00A3; Mon, 6 Jan 2025 18:24:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38E156B00A4; Mon, 6 Jan 2025 18:24:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1947E6B00A1 for ; Mon, 6 Jan 2025 18:24:55 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 964CC1A04D1 for ; Mon, 6 Jan 2025 23:24:54 +0000 (UTC) X-FDA: 82978609308.07.B6E9C36 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf19.hostedemail.com (Postfix) with ESMTP id BA5631A000F for ; Mon, 6 Jan 2025 23:24:52 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Q/sPBrGM"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736205892; h=from:from:sender: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:dkim-signature; bh=hKhRgig6RvBQByFIYLu/f2LHcv9xOxj/hUQxk99BI4o=; b=5vBMBysFaq5L0vSlsrrjVZaNAEBwH/8SVk7cTj4anepltvTNYmlee2KH2/8n1PUzAylWgh FXgw88Ha5ibUTmfM+nRpabdCmIYTrO8mbNTPVmyTLWvqolQ4+kWKRaO1ZuocSt1apXGbLK 7U7UUyxg436xPiFfn4sJJLPOY53/5i4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736205892; a=rsa-sha256; cv=none; b=hLrCFUThTFLJBaAud8hvlss5LA1REwQMkoU9YEaARrEunWn1+MwKMuz7eUe7SIlAu/aTxy NOK0z58IQztFUS2kqpWgW7AobcVgHjg6i91XSeDDePLooVBVPYT6+wJ0aBav7q39tgm40F iB/HLd84lVW0QnWk5UG3PIpvtIxgS3g= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Q/sPBrGM"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=yosryahmed@google.com Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6df83fd01cbso7258186d6.2 for ; Mon, 06 Jan 2025 15:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736205892; x=1736810692; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hKhRgig6RvBQByFIYLu/f2LHcv9xOxj/hUQxk99BI4o=; b=Q/sPBrGMyS4cWc+X3RgBLR47wZs/P4Vb1M4El5nIUhcrNdVNZZaUfphG0whvmdcGi+ 7LbFYq56O61/WKL8R7rQ9ruEE4BznGbtFhaIrBB9bqBroUMNQbfA0Ts3NqDEyCPOqeUK ExWKx6bEi4y0P3wQJQaf4ZxDutN3L6ivWEInbIlqE8lL/wPrcHvLxkyzYEVvgnp/M7bU 21WlcFKivbUo2VOt1l8d9CQcXDm5fv5zTyPcmKCGQZbVvu9+v04xXiLwT+ADSh9wX/2E 0/sgx7mpwrJaDLdTkhSBe2lDmIkBJY5f06qu+jBeF/yd6sEDIFO3NR4/15VdXoNj8gkN 1QDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736205892; x=1736810692; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hKhRgig6RvBQByFIYLu/f2LHcv9xOxj/hUQxk99BI4o=; b=ExA+4CzqhGw5yo0X2A7JhGU5CkTtrYrQZ5X6QSxog9q/9sneIwLUwuJlWQKt803YcF w4F5e3zGdXLwebzBDPUB3x1sbAfUK5zbKfuc2fvpw+njGHXtfK2Ox3B9K19CLqN/Ax1o CePoEyyVaVzBfiDqNNV3xZi91BRNjQN2TdcTw1Mp+fmTR6o2tfkjHsSdcaooMRGukK4d w3r8PUesj9Xt7m76wey8TsSORkdwhzzxPChM/gS0gfNXC0gxV/SGgVZK4T+MHizwvYgU B4hr079VvdaGkzHZUzgziAFwtE5+vNChimMQb6aSmXKhy2XcQmwcmobCts1pYf+XrWLm F6qA== X-Forwarded-Encrypted: i=1; AJvYcCW72yXv6D8VJvA4nR2ROGckJyu9WVZZknA32unfH7UzAUlAbG7FvUJyWhOQgkW6ycgvHDh4d382og==@kvack.org X-Gm-Message-State: AOJu0YwIVnK55fmzNz2dKzR0Sz6JDrr1FqR88+Jk1IYA3ei5gGuQopJv NjXJyJfHsRSbaoTmdaCo4LXj44UVJ6X3AI3PF7E12HQHNcHDV5aU4l9+PHtrxzBRkMG0Gk7KxAF wzM4HpM3hOBABkWvlfVf6zntNlc/q+2Omk+FQGrKtQAOXpZY7tw== X-Gm-Gg: ASbGncsJ09fJTDMtGYOU2op60zPRqIicwJ6R2xxaAVxrfdIjwgvQOXP9xmJkVJJoq58 tVOUrA6ieBV+hFjJ7zcTrDBImsX6Qd9YFxtc= X-Google-Smtp-Source: AGHT+IG9zmeZwtyOnsnBkMeqJ3xK/tqIzpoFJqb89Dat0pQ9PmlCCaYsopKI0if6B3TNWI/WoZHecfDyZLZEo6Y5G7s= X-Received: by 2002:ad4:5aad:0:b0:6d8:d5f6:8c72 with SMTP id 6a1803df08f44-6dd2332e380mr1041760026d6.19.1736205891701; Mon, 06 Jan 2025 15:24:51 -0800 (PST) MIME-Version: 1.0 References: <20241221063119.29140-1-kanchana.p.sridhar@intel.com> <20241221063119.29140-3-kanchana.p.sridhar@intel.com> In-Reply-To: From: Yosry Ahmed Date: Mon, 6 Jan 2025 15:24:15 -0800 X-Gm-Features: AbW1kvY1DpYZkUogZ-GyezP9HOYgzr8x3sGsVp-x_34VwwGW0DIzItdsD6GWGO0 Message-ID: Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching. To: "Sridhar, Kanchana P" Cc: Herbert Xu , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: w3ptdh3gz8yna4y8qcepkjsuaesdw3d6 X-Rspamd-Queue-Id: BA5631A000F X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736205892-214900 X-HE-Meta: U2FsdGVkX1+YPpFm5aNXv81fZe3cNayA3IKcCvBAyuxDAZ2eoybP3wRWoF7bHqGLRx0TPWFr9r1oPjYOicCukmjV2cp2xnL7P2g3KqQIWrZ01TEr5vJgRe1YZWEYLMrfz+N4pR7qapkS/jZEHWNerYPfD9ur6YcaF5CYTdlUUX2hQdIxi7AygXUv1O8141tvg1PvfvGM3cdtcYjNVqR+KeEupdkfn5b+U6Dele9UY1NmKzQ6D30Ickr0kBKJ6W2pxVXTSwaNkvMCt5oaZcSbjnPo4nGwQY6Ks/zS2LLVB1dJM+sWXOE4QkkKJQ08Sl8x5tCVUEqEVSSxO3ylkv2e6zVPVX5YzCJhlFQ+VksD2HpkDq2DmjvyObYTuCV2a+TQ0L4sk/TZc+u9PxnqR831fOOaBsBQVuMJL5EF9Kjhpi3NSe7wGFgYiSJtxO6kbVpajVOF7CUcZbX05qY8C4d5D4J4zDHRpsN+Rna1Bv9g1gMyXLvPDcjV6G+tVpvPnRO75FyHHkx+sCMtejLEDAzpByPHsILMzRoVyviRMnE7F26XWijTQz8L2juODg2imc8IPH0KdoHsmX5b2hjwrsYSfkQQSpln5hG32I1KLKUqf5+o87pUYJl8w3RCAAVVZdvVQSrPxMEVwOyITYP8TWHNrq6E3fdPyTTd8vjWsUyzVmXkGySPYS21uJvdJWD9+Tk9jNNctVeRBT/DMz4LX3kdnkRm1d64W5jJLYcThlPJyVL+EnXGjp5g00zK2AG9Y+ZhH3y83+leLkd6kA8rx+drXACV0SYpPJhRP1lE5vFz4WjAe6JPEusY37M3BUixNOkalEhQQAoJ9RgZ9Chlb+g62zc4D3Ceg6IOqYdtiqVQPsWujrM1Vhf246+dWYpkUfrnKQ4Nnor7CD1TTqDwqeSCLHTUAfXHZJR842vWhpDa+2KS3M3XWssmhin70fidWt1RpTaBHVqEIPpV8kGDzfU ZoFnJBd+ vXwm6LGk5sbp5DSsXGwaOzI0rmHowEEFJAe2gIW0TUsLTXdlrFXZWVutuhAbDZasQCi2/ZPVmEmZ/rlKuN/hmI3zTZeNBVgU9brfvh16w4fe14qwE/eh2kwydwmcodYVvwgdk9wTIOGaGLzJFIzJSKTQtaGoKngAbHTi+EymYPjo2niW5WXGbiaYydBTnuiflHyKeMAEoBJsC18cDOLWTUVo9hMujfraDbP+HGxjNQjj1omw+OKhrbsLrvIgkdk+L5TOIBw08LjDDtZHZgpd6Lnnzx2YTAo8FrOnJ8FxeH8FFKIOPLlm+h8xaIfCAnK2tOmJYKruAKH39BVfv3FyDu/iyWPzII1Tka7pnLXXrsrHuk6e4fVxcopNtNOku4eicIYWM8l3Z51J3zZN66cmuTBiMF1GwSnvaA29dFTi1OBQe+k6d4/zhuaCEq3Ax8zCRkk2lzw+LZ/DgdX9nGuFqisjsSZj0Ah9M9dH3tdzkK58parIjPPlm6WMK/3PpLAc6YMs4MkOrU9x3zH+PjOWZozIyQuiUUFIK4qnp/9bTQATRxpwSaybRB5Qw2VY7UlYjhK8l4t6j93puzkUfxCCZ+i+4A4uY/8Z0mp3wToKVevUKLUk4tjB1VFzGp61qEXnLAY4xpDWMN6+h2k0+Lakne2XPRTuhMiO+qhxoYxNGFPLzV2u6iqugvLlPvN4IYCNzyai7OryzZ8wnjO5G+m3noq5EhgOzlKAqalZmWtqUggLWYMc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jan 6, 2025 at 9:37=E2=80=AFAM Sridhar, Kanchana P wrote: > > Hi Herbert, > > > -----Original Message----- > > From: Herbert Xu > > Sent: Saturday, December 28, 2024 3:46 AM > > To: Sridhar, Kanchana P > > Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org; > > hannes@cmpxchg.org; yosryahmed@google.com; nphamcs@gmail.com; > > chengming.zhou@linux.dev; usamaarif642@gmail.com; > > ryan.roberts@arm.com; 21cnbao@gmail.com; akpm@linux-foundation.org; > > linux-crypto@vger.kernel.org; davem@davemloft.net; clabbe@baylibre.com; > > ardb@kernel.org; ebiggers@google.com; surenb@google.com; Accardi, > > Kristen C ; Feghali, Wajdi K > > ; Gopal, Vinodh > > Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for > > compress/decompress batching. > > > > On Fri, Dec 20, 2024 at 10:31:09PM -0800, Kanchana P Sridhar wrote: > > > This commit adds get_batch_size(), batch_compress() and > > batch_decompress() > > > interfaces to: > > > > First of all we don't need a batch compress/decompress interface > > because the whole point of request chaining is to supply the data > > in batches. > > > > I'm also against having a get_batch_size because the user should > > be supplying as much data as they're comfortable with. In other > > words if the user is happy to give us 8 requests for iaa then it > > should be happy to give us 8 requests for every implementation. > > > > The request chaining interface should be such that processing > > 8 requests is always better than doing 1 request at a time as > > the cost is amortised. > > Thanks for your comments. Can you please elaborate on how > request chaining would enable cost amortization for software > compressors? With the current implementation, a module like > zswap would need to do the following to invoke request chaining > for software compressors (in addition to pushing the chaining > to the user layer for IAA, as per your suggestion on not needing a > batch compress/decompress interface): > > zswap_batch_compress(): > for (i =3D 0; i < nr_pages_in_batch; ++i) { > /* set up the acomp_req "reqs[i]". */ > [ ... ] > if (i) > acomp_request_chain(reqs[i], reqs[0]); > else > acomp_reqchain_init(reqs[0], 0, crypto_req_done, crypto_wait); > } > > /* Process the request chain in series. */ > err =3D crypto_wait_req(acomp_do_req_chain(reqs[0], crypto_acomp_compr= ess), crypto_wait); > > Internally, acomp_do_req_chain() would sequentially process the > request chain by: > 1) adding all requests to a list "state" > 2) call "crypto_acomp_compress()" for the next list element > 3) when this request completes, dequeue it from the list "state" > 4) repeat for all requests in "state" > 5) When the last request in "state" completes, call "reqs[0]->base.comple= te()", > which notifies crypto_wait. > > From what I can understand, the latency cost should be the same for > processing a request chain in series vs. processing each request as it is > done today in zswap, by calling: > > comp_ret =3D crypto_wait_req(crypto_acomp_compress(acomp_ctx->reqs[0]),= &acomp_ctx->wait); > > It is not clear to me if there is a cost amortization benefit for softwar= e > compressors. One of the requirements from Yosry was that there should > be no change for the software compressors, which is what I have > attempted to do in v5. > > Can you please help us understand if there is a room for optimizing > the implementation of the synchronous "acomp_do_req_chain()" API? > I would also like to get inputs from the zswap maintainers on using > request chaining for a batching implementation for software compressors. Is there a functional change in doing so, or just using different interfaces to accomplish the same thing we do today?