[Xen-ia64-devel] Re: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64

2006-05-22 Thread Keir Fraser


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


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


[Xen-ia64-devel] RE: [Xen-devel] Re: [PATCH] Disable auto-balloon on ia64

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

 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

OK, the question by far is that ia64 describes the memory hierarchy 
presented to domain by d-max_pages. Before balloon is ready, we at 
least need to ensure all frames covered by d-max_pages allocated for 
target domain. Then there're two alternatives:
- Keep the first piece of change on increase_reservation, which 
ensures all pages including extra spaces allocated immediately.
- Pass the extra memory size to xen at arch_set_info_guest, and 
then change xen/ia64 to only tell domain maximum pfns as 
d-max_pages-extra_size

Both need to be changed again later if balloon is ready. So I prefer to 
option I which is simpler and can help Alex to do sync quickly. How do 
you think?

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] Re: [PATCH] Disable auto-balloon on ia64

2006-05-22 Thread Alex Williamson
On Mon, 2006-05-22 at 21:33 +0800, Tian, Kevin wrote:
 OK, the question by far is that ia64 describes the memory hierarchy 
 presented to domain by d-max_pages. Before balloon is ready, we at 
 least need to ensure all frames covered by d-max_pages allocated for 
 target domain. Then there're two alternatives:
   - Keep the first piece of change on increase_reservation, which 
 ensures all pages including extra spaces allocated immediately.
   - Pass the extra memory size to xen at arch_set_info_guest, and 
 then change xen/ia64 to only tell domain maximum pfns as 
 d-max_pages-extra_size
 
 Both need to be changed again later if balloon is ready. So I prefer to 
 option I which is simpler and can help Alex to do sync quickly. How do 
 you think?

   I agree, I think we can get by with only the ia64 changes in the
increase_reservation call.  The other option seems more fragile.  Keir,
would you include the first chunk of Kevin's patch as a temporary
solution until we have better ballooning support on xen/ia64 (should be
soon)?  Thanks,

Alex

-- 
Alex Williamson HP Linux  Open Source Lab


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