Re: [PATCH 2/3] mm/swap: account synchronous swap reads as memory stall

[Johannes Weiner]

On Fri, Oct 30, 2026 at 07:16:51PM +0800, Kairui Song wrote:
> On Fri, Oct 30, 2026 at 5:00 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> >
> > On Fri, Oct 30, 2026 at 02:31:42AM +0800, Kairui Song via B4 Relay wrote:
> > > From: Josef Bacik <josef@xxxxxxxxxxxxxx>
> > >
> > > Swap-ins from SWP_SYNCHRONOUS_IO devices such as zram are no longer
> > > counted in PSI memory pressure or in the swapin and thrashing delays of
> > > delay accounting.  Refaults of the workingset from zram, the main input
> > > to userspace OOM handlers like lmkd and systemd-oomd on zram systems,
> > > become invisible in /proc/pressure/memory.
> > >
> > > swap_read_folio() opens the accounting window with
> > > psi_memstall_enter() and delayacct_swapin_start() and, per its comment,
> > > means to count the submission time.  For synchronous devices the
> > > submission is the entire read: swap_bdev_submit_read() does
> > > submit_bio_wait() and completes the folio.  Since reads are batched in
> > > a swap_iocb, swap_read_folio() only queues the folio with
> > > swap_add_folio(), and the bio is submitted later by swap_read_submit()
> > > in the caller, e.g. swapin_sync(), after the window has been closed.
> > > By then the folio is uptodate and unlocked, so the fault does not wait
> > > on the folio lock either and the read time is not counted anywhere.
> > >
> > > Found by code inspection; not reproduced.
> > >
> > > Fix by submitting synchronous reads from within swap_read_folio(), as
> > > was done before the batching, rather than from the caller.  This gives
> > > up batching of readahead for synchronous devices, which do their I/O
> > > inline anyway, in exchange for keeping the accounting simple and in one
> > > place.
> > >
> > > Fixes: dda8fb68b590 ("mm/swap: also use struct swap_iocb for block I/O")
> > > Assisted-by: LLM
> > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> > > Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
> > > Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> >
> > Hm, this isn't a complete fix to the problem described. IO throttling
> > happens at submission time, so there can be significant delays on
> > async devices too that are no longer tracked since the culprit change.
> 
> Yeah you are right! Thanks for the heads up, not only a sync isssue
> indeed, async devices are affected too :(, throttled swap fault also
> went unaccounted.
> 
> > How about keeping the accounting window open across the batch? Opens
> > on first read, closes on submission. A batch with at least one
> > workingset folio is "contaminated" and the whole sequence and
> > submission becomes a stall. Would need to pull the !can_merge flush
> > out of the batch-add function to get the accounting window right but
> > that seems reasonable.
> 
> Won't this cause an amplified PSI reading if only one folio in a batch
> is workingset? Maybe not a big issue though.

Hm, I think the only option to avoid this would be to split the batch
and flush more frequently, which I'm not sure is worth it. The batch
size is only 32 folios...

diff --git a/mm/page_io.c b/mm/page_io.c
index 22e5ac1d298f..806cfe633a95 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -207,6 +207,8 @@ static bool swap_can_merge(struct swap_io_ctx *ctx, struct folio *folio,
 
 	if (ctx->sis != sis)
 		return false;
+	if (rw == READ && ctx->workingset != folio_test_workingset(folio))
+		return false;
 	return sis->ops->can_merge(folio, prev_folio, prev_folio_size, rw);
 }