From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (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 DF73E1E1A31 for ; Mon, 6 Jan 2025 23:24:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736205894; cv=none; b=kKmw5I4F/cLkXg0o9VCQ9JlWNFke0+ai15PauDhITF74NTYdquyXbR/1MUHqHqfbTuVZHFLv7AeSoXjoAPyk6n6qX/9qJmG/mXK4VIUW5rXcblEtAmrvKKX/x/FnnGAWcDdfvQHzcT19/1zcN7RgalSBUtLJnL9k8I1Zmn4tsiQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736205894; c=relaxed/simple; bh=oVl/+D3Bk+0sLTBYRTAp8Sxp098WE+23RntlNThvoGQ=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mesKNF5B3jWvdu7PFAgUrdg2RYkDAqSEakK0KmMtJeYgfROj7WFpXMa0NpfNLDJKfjU3AN3cACXlrM3Xyqq9rhCNaWeRNmeGMMOozeSyifcIZttEvrfCx/55j9GyODyFtbVZ82p37kTHHERx9px+CcBhUPrHUHFCpWCjbxtoU8o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=HREUaA1z; arc=none smtp.client-ip=209.85.219.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HREUaA1z" Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-6dcf63155b0so66415696d6.1 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=vger.kernel.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=HREUaA1zh9ZQjHqTIpfi1b6NrZhGK76WHJbSq/k6Y7mkn2VWdpDGYxbSzJLe8MRuHQ WMcLwHYPfJ9SBYOxhHPI66a1wf1HFJ5A0/WnVQnwJzL1Hp6acRz1Phxpllg7wYVhoHVy RPaJK4Zf22webyNVFTBoVXY8veaixP7O5vEXbTVFcahFUZGZVKg4xpGB+ERiFd9XXTWF s17NuGGj8VhxaWVkKBRcp3cgQAOIl1KQ5QXUsFa/gBCFoqb5dSa4ntIqaQ467/gpDcqL 7vlgKI6r6xiPs2te1PNaazmjNWKzIhg3/pvaNPvVLmaKsRnH4s07sMKufRThk3yn6l/p g7Eg== 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=kcDrDnRF1D5g2nAjSBJNnFNvmvaTfzMUDoN2wpyuICFKc20y1Sdk/MCwDetRomJGZM GpLe/rGHNan7WJVTZVf6TZhzlLT0IGqEx21JoIwo33qv9jFML4mJMltyL+vQvZIK6tu2 K3iEkCWeYCLzFORj+bHmQXkqL/mACpHn6M7z2Eu1kFmsaWDh1EtrjiIM9Dgyuci+EuBE bGBnR886CyuFSDTNlUVC9Oempj7KdGhBwGdlL7OfCkKocpKAa+ujf6hsL6LvcRidKPhq tiySWJbpBhwZ3Xcy0ctUoFRoW+jClSmeTDWm8vm0ZM+n7lf1rBaJgPXLDgt9Z8r7diyA oZxg== X-Forwarded-Encrypted: i=1; AJvYcCXYXL/TJ9RURZ/W7KJUZneT7KbZp+fY3TKFmgzTAW0TSpFQk0pm+7aD7hUdmMxwQY5nWoICFx6LiEclDBg=@vger.kernel.org X-Gm-Message-State: AOJu0Ywd6t1NZiJ50VhlrdVvajE3ywBHe5pGB1B/y1eG907XkIMXxSBt E6p2dfXRNA6K7GXhMNq6Sn8CXteSGX7FrZZr2hlIej5vMcfI5t+Yvcmd74Fm8nuxyQIG726WxVW 54isrVh+6E1vueQ638Os0KWswJ7GjJa16LkUy X-Gm-Gg: ASbGnctjCGn1El552CoUO82Cr2osTS5QTGt8tNpd4zhgqd99f8OpfEzh18g8enV4ylx hZtWf97CgCDSpEsWmCUD80NkhNer4wC1tyFM= 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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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?