public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Dor Laor <dor.laor@qumranet.com>
To: Sukanto Ghosh <sukanto.cse.iitb@gmail.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>, kvm@vger.kernel.org
Subject: Re: Ballooning Queries
Date: Sun, 10 Aug 2008 13:03:28 +0300	[thread overview]
Message-ID: <489EBCF0.50405@il.qumranet.com> (raw)
In-Reply-To: <a85e78f50808091606x47201d2kaa12674c4a74cfc5@mail.gmail.com>

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.

      reply	other threads:[~2008-08-10 10:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-09 18:05 Ballooning Queries Sukanto Ghosh
2008-08-09 18:31 ` Anthony Liguori
2008-08-09 23:06   ` Sukanto Ghosh
2008-08-10 10:03     ` Dor Laor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=489EBCF0.50405@il.qumranet.com \
    --to=dor.laor@qumranet.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=sukanto.cse.iitb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox