Re: Excluding init_on_free for pages for initial balloon down (Xen)

Re: Excluding init_on_free for pages for initial balloon down (Xen)

[Marek Marczykowski-Górecki]

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

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...).

> So we'd need some EXPORT_SYMBOL_FOR_MODULES() magic.

Then this wouldn't be necessary.

> Like an
> 
> 	struct page *alloc_balloon_pages(gfp_t gfp, unsigned int order);
> 
> Where we only support a subset of gfp flags, for example, to now having
> to deal with mempolicy.
> 
> But it needs a bit of code to make it fly, so I am not sure if the page
> allocator wants to support that.


PS adding linux-mm, which I forgot initially...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Excluding init_on_free for pages for initial balloon down (Xen)

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 2028 bytes --]

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]