Re: [PATCH v2] mm/page_alloc: optimize lowmem_reserve max lookup using its semantic monotonicity

[Zi Yan <ziy@nvidia.com>]

On 14 Nov 2025, at 22:02, fujunjie wrote:

> calculate_totalreserve_pages() currently finds the maximum
> lowmem_reserve[j] for a zone by scanning the full forward range
> [j = zone_idx .. MAX_NR_ZONES). However, for a given zone i, the
> lowmem_reserve[j] array (for j > i) is naturally expected to form a
> monotonically non-decreasing sequence in j, not as an implementation
> detail, but as a consequence that naturally arises from the semantics
> of lowmem_reserve[].
>
> For zone "i", lowmem_reserve[j] expresses how many pages in zone i must
> effectively be kept in reserve when deciding whether an allocation class
> that may allocate from zones up to j is allowed to fall back into i. It
> protects less flexible allocation classes (which cannot use higher
> zones) from being starved by more flexible ones.
>
> Viewed from this semantics, it is natural to expect a partial ordering in j:
> as j increases, the allocation class gains access to a strictly larger
> set of fallback zones. Therefore lowmem_reserve[j] is expected to be
> monotonically non-decreasing in j: more flexible allocation classes must
> not be allowed to deplete low zones more aggressively than less flexible
> ones.
>
> In other words, if lowmem_reserve[j] were ever observed to *decrease*
> as j grows, that would be unexpected from the reserve semantics' point of
> view and would likely indicate a semantic change or a misconfiguration.
>
> The current implementation in setup_per_zone_lowmem_reserve() reflects
> this policy by accumulating managed pages from higher zones and applying
> the configured ratio, which results in a non-decreasing sequence. This
> patch makes calculate_totalreserve_pages() rely on that monotonicity
> explicitly and finds the maximum reserve value by scanning backward and
> stopping at the first non-zero entry. This avoids unnecessary iteration
> and reflects the conceptual model more directly. No functional behavior
> changes.
>
> To maintain this assumption explicitly, a comment is added next to
> setup_per_zone_lowmem_reserve() documenting the monotonicity expectation
> and noting that calculate_totalreserve_pages() relies on it.
>
> Changes in v2:
>   - Reword the semantic explanation of lowmem_reserve[] monotonicity to
>     clarify that it arises naturally from its semantics.
>   - Maintain a minimal reference to the invariant in
>     calculate_totalreserve_pages(), with full documentation placed in
>     setup_per_zone_lowmem_reserve().
>
> Signed-off-by: fujunjie <fujunjie1@qq.com>
> ---
>  mm/page_alloc.c | 33 +++++++++++++++++++++++++++++----
>  1 file changed, 29 insertions(+), 4 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>

--
Best Regards,
Yan, Zi