* [PATCH] Disable auto-balloon on ia64
@ 2006-05-22 9:06 Tian, Kevin
2006-05-22 9:37 ` Keir Fraser
0 siblings, 1 reply; 5+ messages in thread
From: Tian, Kevin @ 2006-05-22 9:06 UTC (permalink / raw)
To: Alex Williamson, Keir Fraser; +Cc: xen-devel, xen-ia64-devel
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
>From: Alex Williamson
>Sent: 2006年5月22日 6:30
>
>On Sun, 2006-05-21 at 15:07 -0600, Alex Williamson wrote:
>> diff -r 4dcb93547710 tools/python/xen/xend/image.py
>> --- a/tools/python/xen/xend/image.py Sun May 21 09:55:15 2006
>+0100
>> +++ b/tools/python/xen/xend/image.py Sun May 21 14:25:19 2006
>-0600
>> @@ -146,7 +146,7 @@ class ImageHandler:
>> """@return The memory required, in KiB, by the domain to
>store the
>> 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']:
>> + if 'hvm' in xc.xeninfo()['xen_caps'] and os.uname()[4] !=
>'ia64':
>> mem_kb += 4*1024;
>> return mem_kb
>
> Looks like this is just a partial solution, VTi guests are still
>broken with only this change. Instead, we probably need to look at cset
>10040. I suspect we don't yet have the ballooning support and need to
>do the allocation up front. Thanks,
>
> Alex
We just need to reverse the whole change for ia64, since both domU and domVTI are insert a hole by this auto-balloon patch. Due to missing balloon support on xen/ia64 as you said, both domU and domVTI failed due to this change.
Patch attached.
Thanks,
Kevin
[-- Attachment #2: fix-auto-balloon.patch --]
[-- Type: application/octet-stream, Size: 1824 bytes --]
Following auto-balloon doesn't work for xen/ia64, since balloon
doesn't work yet. Patch's a bit dirty, which however promises ia64
domU and domVTI to boot again.
(Based on fix from Alex)
Signed-off-by Kevin Tian <kevin.tian@intel.com>
diff -r 14717dedba02 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py Sun May 21 20:15:58 2006 +0100
+++ b/tools/python/xen/xend/XendDomainInfo.py Mon May 22 16:43:48 2006 +0800
@@ -29,6 +29,7 @@ import string
import string
import time
import threading
+import os
import xen.lowlevel.xc
from xen.util import asserts
@@ -1264,8 +1265,10 @@ class XendDomainInfo:
m = self.image.getDomainMemory(self.info['memory'] * 1024)
balloon.free(m)
xc.domain_setmaxmem(self.domid, m)
- xc.domain_memory_increase_reservation(self.domid, self.info['memory'] * 1024, 0, 0)
-
+ if os.uname()[4]!='ia64':
+ xc.domain_memory_increase_reservation(self.domid, self.info['memory'] * 1024, 0, 0)
+ else:
+ xc.domain_memory_increase_reservation(self.domid, m, 0, 0)
self.createChannels()
channel_details = self.image.createImage()
diff -r 14717dedba02 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py Sun May 21 20:15:58 2006 +0100
+++ b/tools/python/xen/xend/image.py Mon May 22 16:43:48 2006 +0800
@@ -146,7 +146,7 @@ class ImageHandler:
"""@return The memory required, in KiB, by the domain to store the
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']:
+ if 'hvm' in xc.xeninfo()['xen_caps'] and os.uname()[4]!='ia64':
mem_kb += 4*1024;
return mem_kb
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Disable auto-balloon on ia64
2006-05-22 9:06 [PATCH] Disable auto-balloon on ia64 Tian, Kevin
@ 2006-05-22 9:37 ` Keir Fraser
2006-05-22 9:50 ` Keir Fraser
2006-05-22 15:12 ` Overcommitting memory (was: Disable auto-balloon on ia64) Charles Coffing
0 siblings, 2 replies; 5+ messages in thread
From: Keir Fraser @ 2006-05-22 9:37 UTC (permalink / raw)
To: Tian, Kevin; +Cc: Charles Coffing, xen-devel, Alex Williamson, xen-ia64-devel
On 22 May 2006, at 10:06, Tian, Kevin wrote:
> We just need to reverse the whole change for ia64, since both domU
> and domVTI are insert a hole by this auto-balloon patch. Due to
> missing balloon support on xen/ia64 as you said, both domU and domVTI
> failed due to this change.
The first patch that you work around seems okay to me. That is, it
seems correct that we make initial reservation exclude 'getDomainMemory
headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86
does, rather than up front?
The second bit of your workaround, which applies to getDomainMemory:
I'll wait and see if Charles has anything to say, but otherwise I'll
remove the code that adds the extra slack entirely.
-- Keir
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [PATCH] Disable auto-balloon on ia64
2006-05-22 9:37 ` Keir Fraser
@ 2006-05-22 9:50 ` Keir Fraser
2006-05-22 15:12 ` Overcommitting memory (was: Disable auto-balloon on ia64) Charles Coffing
1 sibling, 0 replies; 5+ messages in thread
From: Keir Fraser @ 2006-05-22 9:50 UTC (permalink / raw)
To: Keir Fraser
Cc: Charles Coffing, Tian, Kevin, xen-devel, Alex Williamson,
xen-ia64-devel
On 22 May 2006, at 10:37, Keir Fraser wrote:
>> We just need to reverse the whole change for ia64, since both domU
>> and domVTI are insert a hole by this auto-balloon patch. Due to
>> missing balloon support on xen/ia64 as you said, both domU and domVTI
>> failed due to this change.
>
> The first patch that you work around seems okay to me. That is, it
> seems correct that we make initial reservation exclude
> 'getDomainMemory headroom'. Shouldn't ia64 reserve extra memory as it
> needs it, as x86 does, rather than up front?
>
> The second bit of your workaround, which applies to getDomainMemory:
> I'll wait and see if Charles has anything to say, but otherwise I'll
> remove the code that adds the extra slack entirely.
Thinking about it, that slack might have been added to give enough
space for shadow page tables for live migration. Also, it shouldn't
give you any problems if you weren't allocating headroom up front -- if
you can fix ia64 to allocate the extra memory as needed then you
shouldn't need either of your workarounds?
-- Keir
^ permalink raw reply [flat|nested] 5+ messages in thread
* Overcommitting memory (was: Disable auto-balloon on ia64)
2006-05-22 9:37 ` Keir Fraser
2006-05-22 9:50 ` Keir Fraser
@ 2006-05-22 15:12 ` Charles Coffing
2006-05-22 15:17 ` Keir Fraser
1 sibling, 1 reply; 5+ messages in thread
From: Charles Coffing @ 2006-05-22 15:12 UTC (permalink / raw)
To: Keir Fraser, Kevin Tian; +Cc: xen-devel, Alex Williamson, xen-ia64-devel
>>> On Mon, May 22, 2006 at 3:37 AM, in message
<de6a6f8a49c55295ad1cedb0718099ef@cl.cam.ac.uk>, Keir Fraser
<Keir.Fraser@cl.cam.ac.uk> wrote:
> On 22 May 2006, at 10:06, Tian, Kevin wrote:
>
>> We just need to reverse the whole change for ia64, since both
domU
>> and domVTI are insert a hole by this auto- balloon patch. Due to
>> missing balloon support on xen/ia64 as you said, both domU and
domVTI
>> failed due to this change.
>
> The first patch that you work around seems okay to me. That is, it
> seems correct that we make initial reservation exclude
'getDomainMemory
> headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86
> does, rather than up front?
>
> The second bit of your workaround, which applies to getDomainMemory:
> I'll wait and see if Charles has anything to say, but otherwise I'll
> remove the code that adds the extra slack entirely.
I think we have a more general problem here.
Xen, historically, hasn't overcommitted memory. But with shadow page
tables and HVM, that's not really true, is it?
Suppose I start up a 256 MB HVM domain running, say, a forking web
server. How much physical RAM does this take? Depends on the load,
doesn't it?
Unless I'm missing something, there is no "big enough" amount of slack,
if you care about reliability. With Yunhong's BUG -> domain_crash
patch, the box shouldn't crash, but the domain still might.
In shadow32.c, I see a FIXME comment that refers to "shadow flush".
Even if such things are done, can you put an upper limit on the runtime
memory overhead for an HVM domain?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Overcommitting memory (was: Disable auto-balloon on ia64)
2006-05-22 15:12 ` Overcommitting memory (was: Disable auto-balloon on ia64) Charles Coffing
@ 2006-05-22 15:17 ` Keir Fraser
0 siblings, 0 replies; 5+ messages in thread
From: Keir Fraser @ 2006-05-22 15:17 UTC (permalink / raw)
To: Charles Coffing; +Cc: Kevin Tian, xen-devel, Alex Williamson, xen-ia64-devel
On 22 May 2006, at 16:12, Charles Coffing wrote:
> In shadow32.c, I see a FIXME comment that refers to "shadow flush".
> Even if such things are done, can you put an upper limit on the runtime
> memory overhead for an HVM domain?
Yes, it ought to be a space/time tradeoff. The shadow pagetables should
be regarded merely as a cache. However, the current shadow mode's
memory handling sucks.
-- Keir
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-05-22 15:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-22 9:06 [PATCH] Disable auto-balloon on ia64 Tian, Kevin
2006-05-22 9:37 ` Keir Fraser
2006-05-22 9:50 ` Keir Fraser
2006-05-22 15:12 ` Overcommitting memory (was: Disable auto-balloon on ia64) Charles Coffing
2006-05-22 15:17 ` Keir Fraser
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.