On 02.03.26 16:11, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 02, 2026 at 03:54:12PM +0100, David Hildenbrand (Arm) wrote:
>>>
>>>> Whatever leaves the buddy shall be zeroed out. If there is a
>>>> double-zeroing happen, the latter could get optimized out by checking
>>>> something like user_alloc_needs_zeroing().
>>>>
>>>> See mm/huge_memory.c:vma_alloc_anon_folio_pmd() as an example where we
>>>> avoid double-zeroing.
>>>
>>> It isn't just reducing double-zeroing to single zeroing. It's about
>>> avoiding zeroing such pages at all. If a domU is started with
>>> populate-on-demand, many (sometimes most) of its pages are populated in
>>> EPT. The idea of PoD is to start guest with high static memory size, but
>>> low actual allocation and fake it until balloon driver kicks in and make
>>> the domU really not use more pages than it has. When balloon driver try
>>> to return those pages to the hypervisor, normally it would just take
>>> unallocated page one by one and made Linux not use them. But if _any_
>>> zeroing is happening, each page first needs to be mapped to the guest by
>>> the hypervisor (one trip through EPT), just to be removed from them a
>>> moment later...
>>
>> The same is true for most balloon drivers, including virtio-balloon.
>>
>> So far nobody really cared about that, though, as init_on_free usually
>> comes with such a high performance price tag that people in cheap VMs
>> (where you overcommit etc) don't enable it.
>>
>> __GFP_BALLOON_OUT is just nasty.
>>
>> We could probably have a special allocation interface (not exposed to
>> arbitrary kernel modules) and have things like mm/balloon.c consume that.
>>
>>
>> IIUC, xen balloon does not use the memory balloon infrastructure,
>> though.
> 
> Is there some fundamental reason for that? By looking at the code, the
> migration to use mm/balloon.c shouldn't be that hard (famous last
> words...).

I wanted to do that for years, but -ENOTIME.

Patches welcome. :-)


Juergen