[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Re: Xenheap disappearance: (was: xen_phys_startfor32b)



> as I frequently see systems with completely empty domain heaps.

Really?  Oh, I see we probably have different default paradigms
for memory allocation.  On Oracle VM, dom0 is by default
launched with 256MB and all remaining memory is "free" and
guests are generally launched with memory==maxmem.  As a
result, it is very unusual to have an empty domheap due
to fragmentation.

I expect you are running without dom0_mem unset, thus
using auto-ballooning from dom0 by default.  And probably
either guests are usually launched with memory<<maxmem or
are using disk='file:...' (which results in dom0 filling
up its page cache) or both.  True?

> *must* be accompanied by a tools change in order to be usable

Yes, I see that it would be a must for your different paradigm,
but less important in the one I am accustomed to.

Thanks,
Dan

> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 17.01.09 00:16 >>>
> >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,
> 
> Yes, that's what I'm trying to say. And I think it's rather 
> likely to happen,
> as I frequently see systems with completely empty domain heaps.
> 
> >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.
> 
> No, I wasn't making the point to ask for not doing 
> improvements in Xen -
> in fact, it's been for a long time that I've been raising the 
> scalability issue
> of the limited Xen heap. I was just trying to point out that 
> the Xen change
> *must* be accompanied by a tools change in order to be usable in other
> than development/test environments.
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.