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

[Sridhar, Kanchana P]

> -----Original Message-----
> From: Nhat Pham <nphamcs@xxxxxxxxx>
> Sent: Monday, December 2, 2024 11:27 AM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@xxxxxxxxx>
> Cc: Yosry Ahmed <yosryahmed@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> linux-mm@xxxxxxxxx; hannes@xxxxxxxxxxx; chengming.zhou@xxxxxxxxx;
> usamaarif642@xxxxxxxxx; ryan.roberts@xxxxxxx; 21cnbao@xxxxxxxxx;
> akpm@xxxxxxxxxxxxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx;
> herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx;
> clabbe@xxxxxxxxxxxx; ardb@xxxxxxxxxx; ebiggers@xxxxxxxxxx;
> surenb@xxxxxxxxxx; Accardi, Kristen C <kristen.c.accardi@xxxxxxxxx>;
> Feghali, Wajdi K <wajdi.k.feghali@xxxxxxxxx>; Gopal, Vinodh
> <vinodh.gopal@xxxxxxxxx>
> 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@xxxxxxxxx> 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