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

[Fujunjie <fujunjie1@qq.com>]

[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]


On Fri Nov 14, 2025 at 8:36 PM UTC, Brendan Jackman wrote:
> On Fri Nov 14, 2025 at 10:40 AM UTC, fujunjie wrote:
>> Although this code is not on a hot path, the revised form is clearer
> Is it...?
>
> If people do think it is clearer, let's at least write the right comment
> in the right place. Instead of having one piece of code
> (calculate_totalreserve_pages()) describe at a distance the behaviour of
> another piece of code (setup_per_zone_lowmem_reserve()), let's describe
> an invariant of the data ("lowmem_reserve is monotonic, up to the first
> zero value"), at the site where the data is defined.
>
> I know sometimes in code this complex we do need these
> "spooky-action-at-a-distance" comments but this doesn't seem like one of
> those places to me.

Thanks for the review, Brendan! Let me clarify the motivation using the 
actual semantics of zone->lowmem_reserve[j], since that meaning is what 
leads to the monotonic property. For a given zone “i” (i.e., 
zone_idx(zone) == i), the entry zone->lowmem_reserve[j] (for j > i) 
represents how many pages in this zone “i” must be treated as reserved 
when evaluating whether an allocation class that is allowed to use zones 
up to “j” may fall back into zone “i”. These reserved pages protect more 
constrained allocations that cannot use higher zones and may rely 
heavily on this lower zone. Because of this meaning, as j increases we 
are considering allocation classes that are able to use a strictly 
larger set of zones. Such classes are more flexible, and therefore we 
should not allow them to consume more low memory than allocation classes 
with a smaller j. Consequently, the reserved amount for zone “i” can 
only stay the same or increase as j increases; it should not decrease. 
setup_per_zone_lowmem_reserve() encodes this semantics directly: as j 
increases, it accumulates the managed pages of higher zones and computes 
zone->lowmem_reserve[j] as managed_pages / ratio[i]. This makes 
zone->lowmem_reserve[j] monotonically non-decreasing in j by design, 
reflecting the intended protection model rather than an accidental 
implementation detail. Given this structure, scanning backward from the 
highest j and taking the first non-zero entry in 
calculate_totalreserve_pages() is a natural way to use the data: the 
maximum reserve for zone “i” must appear at the highest j for which the 
reserve is defined. For readers familiar with how 
zone->lowmem_reserve[j] is constructed, encountering a full forward 
maximum scan can raise the question “why search the entire range when 
the reserve grows monotonically with j?” That said, I agree with your 
point that if users rely on this property, the monotonicity should be 
documented where zone->lowmem_reserve[j] is populated (or near the field 
definition), rather than explained indirectly from 
calculate_totalreserve_pages(). I can move the comment there and keep 
the consuming code simple. I’ll wait a bit to see if others have 
opinions, and if the direction seems agreeable I can send a v2 with the 
comment relocated accordingly. Thanks again for the feedback!

[-- Attachment #2: Type: text/html, Size: 3718 bytes --]