RE: [PATCH v4 10/10] mm: zswap: Compress batching with Intel IAA in zswap_batch_store() of large folios.

["Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>]

> -----Original Message-----
> From: Nhat Pham <nphamcs@gmail.com>
> Sent: Monday, December 2, 2024 11:27 AM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: Yosry Ahmed <yosryahmed@google.com>; linux-kernel@vger.kernel.org;
> linux-mm@kvack.org; hannes@cmpxchg.org; chengming.zhou@linux.dev;
> usamaarif642@gmail.com; ryan.roberts@arm.com; 21cnbao@gmail.com;
> akpm@linux-foundation.org; linux-crypto@vger.kernel.org;
> herbert@gondor.apana.org.au; davem@davemloft.net;
> clabbe@baylibre.com; ardb@kernel.org; ebiggers@google.com;
> surenb@google.com; Accardi, Kristen C <kristen.c.accardi@intel.com>;
> Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal, Vinodh
> <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v4 10/10] mm: zswap: Compress batching with Intel IAA
> in zswap_batch_store() of large folios.
> 
> On Mon, Nov 25, 2024 at 1:54 PM Sridhar, Kanchana P
> <kanchana.p.sridhar@intel.com> wrote:
> >
> > There are some minimal "future-proofing" details such as:
> 
> I don't think they're minimal :)

Sure. Deprecated :), and suggestions being pursued in [1] with the goal of
intercepting with a v5 of this series.

[1]: https://patchwork.kernel.org/project/linux-mm/list/?series=912937

> 
> >
> > 1) The folio_batch: This is the most contentious, I believe, because it
> >      is aimed toward evolving the zswap_batch_store() interface for
> >      reclaim batching, while allowing the folio-error association for the
> >      partial benefits provided by (2). As mentioned earlier, I can delete this
> >      in the next rev if the maintainers feel strongly about this.
> 
> Let's delete it, and focus on the low hanging fruit (large folio zswap storing).

Sure.

> 
> > 2) int* error signature: benefit can be realized today due to the latency
> >     optimization it enables from detecting errors early, localized cleanup,
> >     preventing unwinding state. That said, the same benefits can be realized
> >     without making it a part of the interface.
> 
> This can be done in a separate patch/follow up. It's not related to this work :)

Agreed. Simpler approach with consolidated batching/non-batching code paths
being pursued in [1].

Thanks,
Kanchana