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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <36C81D51-A931-44BA-B58D-223950FD370F@nvidia.com>
Date: Sat, 15 Nov 2025 12:51:36 -0500
From: Zi Yan <ziy@...dia.com>
To: fujunjie <fujunjie1@...com>
Cc: akpm@...ux-foundation.org, vbabka@...e.cz, surenb@...gle.com,
 mhocko@...e.com, jackmanb@...gle.com, hannes@...xchg.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/page_alloc: optimize lowmem_reserve max lookup
 using its semantic monotonicity

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@...com>
> ---
>  mm/page_alloc.c | 33 +++++++++++++++++++++++++++++----
>  1 file changed, 29 insertions(+), 4 deletions(-)
>
Acked-by: Zi Yan <ziy@...dia.com>

--
Best Regards,
Yan, Zi