Re: RFC: better block swap batching and a different take on swap_ops

[Christoph Hellwig <hch@lst.de>]

On Thu, May 28, 2026 at 12:10:48AM -0700, Chris Li wrote:
> I like the direction of this patch series. I suggest you send it out
> as formal patches without the RFC.

I've been planning to do that for two days, but I'm still waiting
for the buildbot result as the buildbot seems to have some delays.

> One observation is that, this patch series aims at situations where
> block io merging would be beneficial. This makes sense for the
> physical block device. However for the memory compression based swap
> interface, block IO merging might not offer additional benefits. What
> do you think about a combination approach that allows the swap back
> end to select whether to use bio merging for swap or not? The end
> result is that file system swap will use your swap_ops flavor. The
> zram and other memory-based swap backends use an API that behaves more
> like Baoquan's original swap_ops series.

There are two approaches how we could do that:  make the can_merge
callback more high-level to avoid merging, or offer additional hooks.

> We can merge your bio merging swap_ops series first and then design
> how to allow swap backends to optionally bypass the bio merging as a
> follow up step.

Yes, I'd rather do that when we have a consumer.  My impression so far
was that the main support way to do compression was zswap which sits
above this, and we would not optimize for low-level compression.  If
we have to do that for some reason we can do reasonable optimizations
for it.