Re: [PATCH] jbd2: fix shrinker scan budget accounting in jbd2_journal_shrink_scan()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] jbd2: CPU spike due to incorrect shrinker nr_scanned accounting
--

commit 47731fd468777a6abc87ac06fd933280e1966163
Author: Qiliang Yuan <odys.yuan@gmail.com>

jbd2: fix shrinker scan budget accounting in jbd2_journal_shrink_scan()

This commit updates the jbd2 checkpoint shrinker's scan budget accounting
by calculating the number of scanned items, and returning SHRINK_STOP if
no items were scanned.

> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 09efa337649e2..2602e5946cc14 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
[ ... ]
> @@ -1262,10 +1262,26 @@ static unsigned long jbd2_journal_shrink_scan(struct shrinker *shrink,
>  	trace_jbd2_shrink_scan_enter(journal, sc->nr_to_scan, count);
>  
>  	nr_shrunk = jbd2_journal_shrink_checkpoint_list(journal, &nr_to_scan);
> +	sc->nr_scanned = sc->nr_to_scan - nr_to_scan;

[Severity: High]
Will this correctly account for the items that were scanned but not freed?

Looking at jbd2_journal_shrink_checkpoint_list() in fs/jbd2/checkpoint.c,
nr_to_scan is only decremented by the number of freed items:

    freed = journal_shrink_one_cp_list(transaction->t_checkpoint_list,
                                       JBD2_SHRINK_BUSY_SKIP, &released);
    nr_freed += freed;
    (*nr_to_scan) -= min(*nr_to_scan, freed);

Furthermore, journal_shrink_one_cp_list() explicitly skips busy buffers
without them counting towards the freed total:

    if (type == JBD2_SHRINK_BUSY_SKIP && jh->b_transaction)
        continue;

This effectively sets sc->nr_scanned to the number of freed items, not the
actual number of scanned items.

The shrinker API expects sc->nr_scanned to reflect the actual amount of work
done (items scanned). If the shrinker scans many busy buffers but frees very
few of them, it reports a tiny number of scanned items. 

Can this cause do_shrink_slab() to repeatedly re-invoke the shrinker without
meaningfully reducing its total_scan budget, leading to high CPU usage or
potential soft lockups under memory pressure?

>  
>  	count = percpu_counter_read_positive(&journal->j_checkpoint_jh_count);
>  	trace_jbd2_shrink_scan_exit(journal, nr_to_scan, nr_shrunk, count);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-fix-jbd2-shrink-scan-nr-scanned-v1-1-e6f4016ec699@gmail.com?part=1