Re: [PATCH v6 08/15] mm/mglru: lift youngest gen protection for higher priority

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/mglru: unfilled commit placeholder and stale description in
  changelog
--

commit 357b36306d9c0f7d5cb9a3bda097730f4118d2a4
Author: Kairui Song <kasong@tencent.com>

mm/mglru: lift youngest gen protection for higher priority

This commit adjusts the upper generation bound in scan_folios() based on
reclaim priority so that the youngest generation is only scanned when
sc->priority drops to or below DEF_PRIORITY / 2.

> The problem is when aging can't catch up with reclaimer, reclaimers will
> all abort early seeing there is only empty gens, or only two gens left.
> Proactive aging won't help eigher because there will be limited threads
> doing aging, but there could be unlimited threads doing reclaim, which
> is a fundommental limitation of MGLRU. One way to avoid this is to use a
> aging lock, like in commit .... However, aging lock caused several
> jitter when under huge pressure, and was reported to be causing
> obserable lags already on Android.
>
> What's more, the gen model somehow contradicts with the goal of
> swappiness, which aim to reduce IO cost instead of following hotness
> blindly.
>
> So instead, let's lift the protection based on priority. With default
> priority, we still fully respect the MIN_NR_GEN protection. But as the
> priority raised, allow it to reclaim younger gens step by step.

[Severity: Low]
Does the commit message match what this patch changes relative to earlier
commit "mm/mglru: lift the forced protection of reclaimer" in the series?

That earlier patch already removed the MIN_NR_GENS early return and allowed
non-default priorities to scan up to lrugen->max_seq, whereas this patch
restricts sc->priority > DEF_PRIORITY / 2 to lrugen->max_seq - 1 (and sets
DEF_PRIORITY to lrugen->max_seq - MIN_NR_GENS) to keep protecting the
youngest generation until severe pressure.  Also, the second paragraph has an
unfilled "like in commit ...." placeholder and a few typos ("eigher",
"fundommental", "obserable").

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110202025.25736-1-baohua@kernel.org?part=8