[Xen-ia64-devel] RE: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for HVM domains
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
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
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
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
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
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