-----Original Message-----
> From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
> Sent: Friday, January 16, 2009 1:12 AM
> >>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 15.01.09 19:51 >>>
> >I think the patch you attached will work just fine for you
> for now. If your
> >stuff goes in before getting rid of xenheap restrictions on
> x86/64, then I
> >would take this patch at that time. But I think that's
> unlikely. Well, I
> >hope it is, unless I stall on my xenheap patch again. :-)
>
> I'd hope that too, because the patch as is must not go in, as
> it would break
> other assumptions afaics: At present, the tools balloon out
> of Dom0 exactly
> the amount needed for creating pv domains (I think there's
> some slack for
> hvm ones), so the fact that the domain heap now serves
> xmalloc requires
> that there always be some extra space available in Xen (also to serve
> dynamic allocations). Additionally I think the minimum even a
> temporary
> patch like this should do is fall back to allocating from the
> Xen heap when
> the domain heap is unable the supply the requested amount.
Jan --
I'm not sure what you are getting at. Are you saying that
creating a domain takes (big)MB from domheap, then later
(little)KB from xenheap, and if we combine domheap and xenheap,
the tools might launch a domain when available memory is
greater than (big)MB but smaller than (big)MB+(small)KB,
and that will result in the tools thinking the domain
can launch but it won't? I suppose that's possible,
but exceedingly unlikely. And I think Keir's plan will
have the same problem. Sounds like a tools bug, not a
reason to avoid modernizing Xen memory management.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home