Re: re: [Xen-devel] Xen balloon driver discuss

[hotmaim <tinnycloud@xxxxxxxxxxx>]

Hi George:

        Appreciate for the details, I get more understandings but still have 
some confusions.
   1.Is it necessery to balloon to max-target at dom U right startup?(for, xm 
cr xxx.hvm maxmem=2048 memory=1024; max-target is 2048-1024) Say is it safe to 
balloon to let the guest has only 512M memory in total? or 1536 M(in this 
situation, i guess the pod entry will 
also reduce and extra 512M memory will be added to Pod cache,right)?

2. Suppose we have a xen wide PoD memorym pool, that is accessable for every 
guest domains, when the guest needs a page, it get the page from the pool, and 
we can still use 
balloon strategy to have the guest free pages back to the pool.  So if the 
amount of all domain 
memory inuse is less than host physial memory, it is safe. And when no memory 
available from
host, domain need new memory may pause for for waiting for others to free, or 
use swap memory, is it possible? 

3. If item 2 is possible, it looks more like tmem, what will tmem do when all 
memory on request is larger than host physical memory? I will have detail look 
tomorrow.

Thanks for your kindly help.  



From my iPad

2010-11-29，19:19，George Dunlap <George.Dunlap@xxxxxxxxxxxxx> ：

> On 29/11/10 10:55, tinnycloud wrote:
>> So that is, if we run out of PoD cache before balloon works, Xen will 
>> crash domain(goto out_of_memory),
> 
> That's right; PoD is only meant to allow a guest to run from boot until
> the balloon driver can load.  It's to allow a guest to "boot ballooned."
> 
>> and at this situation, domain U swap(dom U can’t use swap memory) is not 
>> available , right?
> 
> I don't believe swap and PoD are integrated at the moment, no.
> 
>> And when balloon actually works, the pod cached will finally decrease to 
>> 0, and no longer be used any more, right?
> 
> Conceptually, yes.  What actually happens is that ballooning will reduce
> it so that pod_entries==cache_size.  Entries will stay PoD until the
> guest touches them.  It's likely that eventually the guest will touch
> all the pages, at which point the PoD cache will be 0.
> 
>> could we use this method to implement a tmem like memory overcommit?
> 
> PoD does require guest knowledge -- it requires the balloon driver to be
> loaded soon after boot so the so the guest will limit its memory usage.
> It also doesn't allow overcommit.  Memory in the PoD cache is already
> allocated to the VM, and can't be used for something else.
> 
> You can't to overcommit without either:
> * The guest knowing that it might not get the memory back, and being OK
> with that (tmem), or
> * Swapping, which doesn't require PoD at all.
> 
> If you're thinking about scanning for zero pages and automatically
> reclaiming them, for instance, you have to be able to deal with a
> situation where the guest decides to use a page you've reclaimed but
> you've already given your last free page to someone else, and there are
> no more zero pages anywhere on the system.  That would mean either just
> pausing the VM indefinitely, or choosing another guest page to swap out.
> 
> -George
> 
>> 
>> *From:* Chu Rui [mailto:ruichu@xxxxxxxxx]
>> *TO:* tinnycloud
>> *CC:* xen-devel@xxxxxxxxxxxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx; 
>> dan.magenheimer@xxxxxxxxxx
>> *Subject:* Re: [Xen-devel] Xen balloon driver discuss
>> 
>> I am also interested with tinnycloud's problem.
>> 
>> It looks that the pod cache has been used up like this:
>> 
>> if ( p2md->pod.count == 0 )
>> goto out_of_memory;
>> 
>> George, would you please take a look on this problem, and, if possbile, 
>> tell a little more about what does PoD cache mean? Is it a memory pool 
>> for PoD allocation?
>> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel