Re: [PATCH 3/7] mm/swap: also use struct swap_iocb for block I/O

[Christoph Hellwig <hch@lst.de>]

On Thu, Jul 16, 2026 at 12:03:22AM +0800, Kairui Song wrote:
> > -static void sio_write_complete(struct kiocb *iocb, long ret)
> > +static bool swap_can_merge(struct swap_io_ctx *ctx, struct folio *folio,
> > +		int rw)
> 
> Will a bool rw suits better?

Not really.  Bools as arguents always have the downside that it is
really hard to guess what they mean based on the callsite.

While READ/WRITE really should be enum, it's probably the best we have
right now.

> > -	bio_add_folio_nofail(&bio, folio, folio_size(folio), 0);
> 
> bio_add_folio_nofail also increased bi_vcnt, now it's open coded and
> bi_vcnt stays zero, it's not used right now, could there be any user
> of it in the future?

bi_vcnt only exists to assist bio_add_page*/bio_add_folio*. So if we
assign the bio_vecs manually we don't need it.  If we ever switch
to using bio_add_folio_nofail we'd need it, but then we'd already
maintain it in there :)

> So this removes swap_writepage_bdev_sync (which was calling submit_bio_wait),
> we are replying on a later swap_write_submit, and just add the folio to ctx.

For SWP_SYNCHRONOUS_IO, yes.

> Before the series, pageout will detect for writeback finished and clean
> pages under PAGE_SUCCESS, if the IO of a page is done and writeback flag
> cleaned, the page get released immediately. But now, almost all pages
> will be put back to the LRU waiting for rotation. This also make the
> reclaim have a stronger bias towards reclaim files, and anon reclaim
> become less effective.
> 
> I do observe a real performance regression with classical LRU and ZRAM,
> ordinary swap seems also very slightly effected but could be noise,
> test is done on my laptop by building the kernel using make -j12 and
> tinyconfig in a 2G VM with mild pressure:

> Before this series (with 8G ZRAM only):
> 175.39user 125.89system 0:40.54elapsed
> 26581840inputs+0outputs (1186391major+22698964minor)pagefaults
> 
> After this sereis:
> 165.59user 216.02system 1:04.06elapsed <- the problemic one.
> 53531464inputs+0outputs (2550441major+31974007minor)pagefaults
> 
> Because all anon folios will be derfer freed on next iteration of the LRU,
> which caused a much higher memory pressure.

So this is zswap which does set SWP_SYNCHRONOUS_IO.  I guess forcing
a submit after each bio_vec for SWP_SYNCHRONOUS_IO might make some
sense as a workaround, although it is a bit ugly.