> -----Original Message----- > From: Johannes Weiner <hannes@xxxxxxxxxxx> > Sent: Thursday, November 7, 2024 9:31 AM > To: Sridhar, Kanchana P <kanchana.p.sridhar@xxxxxxxxx> > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; > yosryahmed@xxxxxxxxxx; nphamcs@xxxxxxxxx; > chengming.zhou@xxxxxxxxx; usamaarif642@xxxxxxxxx; > ryan.roberts@xxxxxxx; Huang, Ying <ying.huang@xxxxxxxxx>; > 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>; zanussi@xxxxxxxxxx; Feghali, Wajdi K > <wajdi.k.feghali@xxxxxxxxx>; Gopal, Vinodh <vinodh.gopal@xxxxxxxxx> > Subject: Re: [PATCH v3 11/13] mm: zswap: Allocate acomp_batch_ctx > resources for a given zswap_pool. > > On Wed, Nov 06, 2024 at 11:21:03AM -0800, Kanchana P Sridhar wrote: > > If the zswap_pool is associated with an acomp_alg/crypto_acomp that has > > registered batch_compress() and batch_decompress() API, we can allocate > the > > necessary batching resources for the pool's acomp_batch_ctx. > > > > This patch makes the above determination on incurring the per-cpu memory > > footprint cost for batching, and if so, goes ahead and allocates > > SWAP_CRYPTO_BATCH_SIZE (i.e. 8) acomp_reqs/buffers for the > > pool->acomp_batch_ctx on that specific cpu. > > > > It also "remembers" the pool's batching readiness as a result of the above, > > through a new > > > > enum batch_comp_status can_batch_comp; > > > > member added to struct zswap_pool, for fast retrieval during > > zswap_store(). > > > > This allows us a way to only incur the memory footprint cost of the > > pool->acomp_batch_ctx resources for a given cpu on which zswap_store() > > needs to process a large folio. > > > > Suggested-by: Yosry Ahmed <yosryahmed@xxxxxxxxxx> > > Suggested-by: Ying Huang <ying.huang@xxxxxxxxx> > > Signed-off-by: Kanchana P Sridhar <kanchana.p.sridhar@xxxxxxxxx> > > A general observation: this is a lot of code for a hardware specific > feature that many CPUs and architectures do not support. Please keep > the code self-contained, and wrap struct members and functions in a > new CONFIG option, so that not everybody has to compile this in. Thanks for this suggestion! Sure, I will address this in v4. Thanks, Kanchana
