[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains

2006-05-22 Thread Tian, Kevin
From: Charles Coffing
Sent: 2006年5月20日 3:59
 On Thu, May 18, 2006 at 10:23 PM, in message
[EMAIL PROTECTED]
orp.intel.com,
Jiang, Yunhong [EMAIL PROTECTED] wrote:
 Hi, Charles
  Just one suggestion, for  xen- hvm- auto- balloon.diff, how
about
 change
  xc.domain_setmaxmem(self.domid, m)

 to
  xc.domain_setmaxmem(self.domid, self.info['memory']
*
1024)

Ideally, yes, I would agree.  But later, in qemu, another
increase_reservation() is called.  If I make the suggested change, I
suspect that qemu will fail to get its memory.

Or is this upper limit not checked when increase_reservation() is
called from dom0?

BTW, could you please explain why following change is required:

+given amount, also in KiB.  This is normally just mem, but if 
HVM is
+supported, keep a little extra free.
+if 'hvm' in xc.xeninfo()['xen_caps']:
+mem_kb += 4*1024;
+return mem_kb

Why do you need to reserve extra memory even for domU as long as 
the platform supports hvm feature? 

P.S I'll send a patch to reverse this change for ia64, since balloon doesn't 
work for xen/ia64 yet and thus we have to allocate all memory at creation 
time.

Thanks,
Kevin

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains

2006-05-22 Thread Keir Fraser


On 22 May 2006, at 09:51, Tian, Kevin wrote:


Why do you need to reserve extra memory even for domU as long as
the platform supports hvm feature?

P.S I'll send a patch to reverse this change for ia64, since balloon 
doesn't
work for xen/ia64 yet and thus we have to allocate all memory at 
creation

time.


It would be nice to avoid needing that kludge at all even on x86. It 
isn't entirely clear to me why it's needed. If it's causing problems 
for ia64 I'm inclined to remove it unless there is a concrete reason 
for keeping it.


 -- Keir


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains

2006-05-22 Thread Tian, Kevin
From: Keir Fraser [mailto:[EMAIL PROTECTED]
Sent: 2006年5月22日 17:06


On 22 May 2006, at 09:51, Tian, Kevin wrote:

 Why do you need to reserve extra memory even for domU as long as
 the platform supports hvm feature?

 P.S I'll send a patch to reverse this change for ia64, since balloon
 doesn't
 work for xen/ia64 yet and thus we have to allocate all memory at
 creation
 time.

It would be nice to avoid needing that kludge at all even on x86. It
isn't entirely clear to me why it's needed. If it's causing problems
for ia64 I'm inclined to remove it unless there is a concrete reason
for keeping it.

  -- Keir

Yes, that breaks xen/ia64 for both domU and domVTI. Though I sent 
out a workaround just now, it's better if you can reverse it directly.

Thanks,
Kevin

___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains

2006-05-22 Thread Keir Fraser


On 22 May 2006, at 15:51, Charles Coffing wrote:


HVM domains need some extra memory free for the shadow page tables,
otherwise they may crash the entire machine while they are running, or
the HVM domain itself may crash (exact behavior depends on whether you
have Yunhong's patch to change BUGs to domain_crash).

This slack space is calculated into the memory size for HVM domains,
but what happens if you then start a PV domain afterwards?  Only the
minimally required memory is freed up, then the PV domain takes it all,
leaving the HVM domain with no slack == crash.


Where does the slack from the previous HVM guest startup go? Are you 
saying that dom0 only frees up PV-guest-size minus existing-slack?


 -- Keir


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains

2006-05-22 Thread Keir Fraser


On 22 May 2006, at 16:15, Charles Coffing wrote:


Where does the slack from the previous HVM guest startup go? Are you



saying that dom0 only frees up PV- guest- size minus existing-

slack?

Correct.

Unless, of course, the HVM domain has eaten up some of the slack in the
mean-time, in which case dom0 frees up PV-guest-size minus
remaining-slack.


The auto-ballooning logic is shagged then. xend should keep track of 
memory requirements (inc. max overheads) of every domain, then ensure 
dom0 memory usage is no greater than total memory minus sum of all 
other domains' memory requirements. How hard can that be? (Too hard for 
original author I guess ;-) ).


Anyway, I'm going to back out the 4MB slack hack. Auto-ballooning can 
never be stable in its current form (consider a guest that temporarily 
balloons down from 128MB to 64MB, then another (HVM) guest starts, then 
it tries to balloon back to 128MB -- it'll fail, and the HVM guest will 
lose any headroom it required).


 -- Keir


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel


[Xen-ia64-devel] Re: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains

2006-05-22 Thread Keir Fraser


On 22 May 2006, at 16:38, Keir Fraser wrote:

Unless, of course, the HVM domain has eaten up some of the slack in 
the

mean-time, in which case dom0 frees up PV-guest-size minus
remaining-slack.


The auto-ballooning logic is shagged then. xend should keep track of 
memory requirements (inc. max overheads) of every domain, then ensure 
dom0 memory usage is no greater than total memory minus sum of all 
other domains' memory requirements. How hard can that be? (Too hard 
for original author I guess ;-) ).


Anyway, I'm going to back out the 4MB slack hack. Auto-ballooning 
can never be stable in its current form (consider a guest that 
temporarily balloons down from 128MB to 64MB, then another (HVM) guest 
starts, then it tries to balloon back to 128MB -- it'll fail, and the 
HVM guest will lose any headroom it required).


Actually, since there is an argument for keeping it for live migration, 
I'll keep it for the time being. But it does sound like auto-ballooning 
needs some more thought.


I'll apply a suitable patch for ia64 shortly

 -- Keir


___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel