Re: [RFC PATCH] mm/khugepaged: cap pageblock contribution to min_free_kbytes

[Nimrod Oren]

On 27/07/2026 13:52, Lorenzo Stoakes (ARM) wrote:
> On Fri, Jul 17, 2026 at 10:58:45AM -0400, Zi Yan wrote:
>> On 17 Jul 2026, at 9:36, Lorenzo Stoakes (ARM) wrote:
>>> Maybe a simpler version would be to just attack the issue we actually have
>>> with it - it uses too much damn memory :)
>>>
>>> So maybe something like the attached? (you'd probably want to make this a
>>> sysctl or at least a defined value of course)
>>
>> The approach below makes sense to me. In terms of the actual cap size,
>> I asked Codex to check what possible pageblock_size and their reserved
>> sizes:
>>
>> 1. 1MB pageblock size (s390) and 11MB per zone,
>> 2. 2MB pageblock size and 22MB per zone,
>> 3. 8MB pageblock size and 88MB per zone,
>> 4. 16MB pageblock size and 176MB per zone,
>> 5. 32MB pageblock size and 352MB per zone,
>> 6. 128MB pageblock size and 1.375GB per zone,
>> 7. 512MB pageblock size and 5.5GB per zone.
>>
>> 1GB makes sense to me. 512MB might also work.
> 
> Yeah I felt this was a bit of a 'dumb' solution but ultimately if we are
> saying 'restrict how much memory this uses to something sane' then that's
> what we should just do.
> 
> It might be a good bandaid at least for this issue which is ongoing, well
> known, and painful.
> 
> I think at 352MB per zone and 2-3 zones for 32 MiB pageblock, plus reserves
> of 2*512 MiB for 512 MiB pageblock makes 1 GiB a sensible choice here
> overall.


It's worth noting that while users who need more headroom can simply
raise min_free_kbytes further via sysctl, those who wish to lower the
value can't set it persistently since set_recommended_min_free_kbytes()
may raise it back to the recommended value.

I think 1 GiB sounds good, but given this behavior where raising is more
accessible than lowering, I wonder if we should opt for a lower value.

A new sysctl for the cap could address this, but I'm not sure whether
adding one would be justified.