Re: [PATCH v2 0/8] Batched zswap_store() framework with compression batching

[Yosry Ahmed]

> > As mentioned in the previous version, I cannot reproduce these results,
> > mainly because the noise is too high. Digging a bit deeper, it's because
> > the throttling from memory.high varies. Hacking in a change to make
> > calculate_high_delay() always return 0 (no memory.high stalls) paints a
> > clearer picture about throughput improvements from the series up to
> > patch 6 and patch 8. With that, I see 1-2% improvement in throughput
> > with patch 6, and almost no improvement with patch 8 on top. Similarly,
> > for zswap store latency for high-order folios, I see a slight (~1-2%)
> > improvement with patch 6, but almost none with patch 8 on top.
>
> Thanks Yosry, for sharing this. Let me also see if I can replicate
> this hack on my end, and its impact on latency.
>
> >
> > In order to make meaningful progress, can you send patches 5-6
> > separately? I assume that 1-4 are prep for 7-8, so 5-6 are standalone. I
> > also think patch 6 will be simplified if we drop the prep work for
> > patches 7-8?
>
> It shouldn't be a problem to send patches 5-6 separately, but I would
> like to measure the latency impact with the hack and confirm the
> latency results in my environment, so we can figure out a plan on how
> to proceed. Patches 5-6 alone only achieve bulk allocation of
> zswap_entries. It could be possible to bundle in patch 8, which
> generalizes the store batching framework, but let's revisit on how
> best to make meaningful progress.

I am questioning the benefit of the compression batching based on the
results I am seeing.

>
> Patches 5-6 have a dependency on the batch_size for allocating
> acomp_ctx resources, which is for the compress batching improvements
> in patch 7-8.

I assume that this code can be dropped from patch 6 if it will be sent
with patch 5 as a standalone series.