Ballooning Queries

Ballooning Queries

[Sukanto Ghosh]

I understand the idea behind ballooning as " it effectively increases
or decreases the amount of physical memory given to the guest, with
the help of the guest's native memory management algorithms". The
benefit is obvious in cases where the hypervisor does a hard
partitioning of the memory between the guests. The guest vm (virtual
memory manager) will indirectly say that these are my least used
pages, or the safest candidates for eviction.

But in case of kvm, the guest memory is itself allocated and managed
by the host linux vm. So, suppose if the guest evicts a lru page
(which might even not actually reside in host physical memory at the
time) and even the host chooses a lru page for eviction, the host
decision is better in a sense that this page is definitely residing in
the physical memory. So, are we gaining from using a balloon driver in
the guest.

The only difference I see is that the balloon driver will always be
giving us a page used by the guest. On the other hand, the linux vm
will select a page from the entire physical memory, so it might
penalise a host application page. But I don't see any benefit because
of this. In fact for smaller no. of pages, most likely the guest will
choose the pages which have already been swapped out by the host linux
vm (the more recently used pages are the one which actually stay in
the physical memory).

Am I missing something ? I hope I have made the reason for my confusion clear.


Also, I have read about some 'balloon userspace component' in kvm,
what does it do ? Does it talk to the virtio balloon driver in the
linux and keeps giving us some statistics for monitoring purposes ? Is
there any other use ?

Where can I get the source for this balloon userspace component ? ( I
read that Avi is going to merge it, but can I have a look at it now
(any patch) ?


-- 
Thanks and Regards,
Sukanto Ghosh

Re: Ballooning Queries

[Anthony Liguori]

Sukanto Ghosh wrote:
> I understand the idea behind ballooning as " it effectively increases
> or decreases the amount of physical memory given to the guest, with
> the help of the guest's native memory management algorithms". The
> benefit is obvious in cases where the hypervisor does a hard
> partitioning of the memory between the guests. The guest vm (virtual
> memory manager) will indirectly say that these are my least used
> pages, or the safest candidates for eviction.
>
> But in case of kvm, the guest memory is itself allocated and managed
> by the host linux vm. So, suppose if the guest evicts a lru page
> (which might even not actually reside in host physical memory at the
> time) and even the host chooses a lru page for eviction, the host
> decision is better in a sense that this page is definitely residing in
> the physical memory. So, are we gaining from using a balloon driver in
> the guest.
>   

What ballooning is useful for in KVM, is reducing the amount of memory a 
guest uses by a large amount.  It's not terribly useful for shaving a 
few dozen MBs from a guest, but it is useful for dropping a 1GB guest 
down to 512GB.

Since the guest tells the host what portions of it's memory it won't be 
using, we can evict it completely from memory (it's not even swapped, 
it's just deleted).

> The only difference I see is that the balloon driver will always be
> giving us a page used by the guest. On the other hand, the linux vm
> will select a page from the entire physical memory, so it might
> penalise a host application page. But I don't see any benefit because
> of this. In fact for smaller no. of pages, most likely the guest will
> choose the pages which have already been swapped out by the host linux
> vm (the more recently used pages are the one which actually stay in
> the physical memory).
>
> Am I missing something ? I hope I have made the reason for my confusion clear.
>
>
> Also, I have read about some 'balloon userspace component' in kvm,
> what does it do ? Does it talk to the virtio balloon driver in the
> linux and keeps giving us some statistics for monitoring purposes ? Is
> there any other use ?
>   

In general, paravirtual drivers in KVM are implemented in two parts.  A 
"front-end" that runs in the guest and a "back-end" that runs in the 
host.  For KVM, all of the current front-ends run in the guest kernel 
and all of the back-ends run in the host userspace (QEMU).

> Where can I get the source for this balloon userspace component ? ( I
> read that Avi is going to merge it, but can I have a look at it now
> (any patch) ?
>   

Check out the mailing list for the patches.  You need MMU notifiers for 
it to be effective though.

Regards,

Anthony Liguori

Re: Ballooning Queries

[Sukanto Ghosh]

On Sat, Aug 9, 2008 at 2:31 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Sukanto Ghosh wrote:
>>
>> I understand the idea behind ballooning as " it effectively increases
>> or decreases the amount of physical memory given to the guest, with
>> the help of the guest's native memory management algorithms". The
>> benefit is obvious in cases where the hypervisor does a hard
>> partitioning of the memory between the guests. The guest vm (virtual
>> memory manager) will indirectly say that these are my least used
>> pages, or the safest candidates for eviction.
>>
>> But in case of kvm, the guest memory is itself allocated and managed
>> by the host linux vm. So, suppose if the guest evicts a lru page
>> (which might even not actually reside in host physical memory at the
>> time) and even the host chooses a lru page for eviction, the host
>> decision is better in a sense that this page is definitely residing in
>> the physical memory. So, are we gaining from using a balloon driver in
>> the guest.
>>
>
> What ballooning is useful for in KVM, is reducing the amount of memory a
> guest uses by a large amount.  It's not terribly useful for shaving a few
> dozen MBs from a guest, but it is useful for dropping a 1GB guest down to
> 512GB.
>
> Since the guest tells the host what portions of it's memory it won't be
> using, we can evict it completely from memory (it's not even swapped, it's
> just deleted).
>

But for deleting these pages shouldn't it be ensured that the guest
remains under the illusion that these pages are least recently used
(may be, by modifying the guest pte for those pages, so the reference
bits are always set for them) and the guest's page eviction algorithm
won't touch these pages. Later on when it is possible to give back the
guest those pages, you remove this illusion.

Another alternative will be, not to have the guest under any sort of
illusion and give it back the pages when it wants to evict them. But
this will defeat the purpose of having the balloon.


Which way is it done in kvm/linux ?



-- 
Regards,
Sukanto Ghosh

Re: Ballooning Queries

[Dor Laor]

Sukanto Ghosh wrote:
> On Sat, Aug 9, 2008 at 2:31 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Sukanto Ghosh wrote:
>>     
>>> I understand the idea behind ballooning as " it effectively increases
>>> or decreases the amount of physical memory given to the guest, with
>>> the help of the guest's native memory management algorithms". The
>>> benefit is obvious in cases where the hypervisor does a hard
>>> partitioning of the memory between the guests. The guest vm (virtual
>>> memory manager) will indirectly say that these are my least used
>>> pages, or the safest candidates for eviction.
>>>
>>> But in case of kvm, the guest memory is itself allocated and managed
>>> by the host linux vm. So, suppose if the guest evicts a lru page
>>> (which might even not actually reside in host physical memory at the
>>> time) and even the host chooses a lru page for eviction, the host
>>> decision is better in a sense that this page is definitely residing in
>>> the physical memory. So, are we gaining from using a balloon driver in
>>> the guest.
>>>
>>>       
>> What ballooning is useful for in KVM, is reducing the amount of memory a
>> guest uses by a large amount.  It's not terribly useful for shaving a few
>> dozen MBs from a guest, but it is useful for dropping a 1GB guest down to
>> 512GB.
>>
>> Since the guest tells the host what portions of it's memory it won't be
>> using, we can evict it completely from memory (it's not even swapped, it's
>> just deleted).
>>
>>     
>
> But for deleting these pages shouldn't it be ensured that the guest
> remains under the illusion that these pages are least recently used
> (may be, by modifying the guest pte for those pages, so the reference
> bits are always set for them) and the guest's page eviction algorithm
> won't touch these pages. Later on when it is possible to give back the
> guest those pages, you remove this illusion.
>   
The guest pins the ballooned pages in memory and it won't swap them.
It's simpler than hacking the LRU data.
> Another alternative will be, not to have the guest under any sort of
> illusion and give it back the pages when it wants to evict them. But
> this will defeat the purpose of having the balloon.
>
>
> Which way is it done in kvm/linux ?
>
>
>
>   
The guest is not under any illusion, it's para virtualization and the 
guest kernel is aware about
all these pages.
Host request the balloon to grow->guest allocates pages and does not 
touch them -> host frees these pages.
The opposite way for balloon deflate.