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

Re: [Xen-devel] a ton of kernel issues



On Wed, Dec 14, 2011 at 01:05:31AM +0400, George Shuklin wrote:
> 
> On 13.12.2011 17:17, David Vrabel wrote:
> >>>>pv_ops is still have some issues with memory limits, but any
> >>>>new kernel (3.0+) will boot normal and operates with very
> >>>>minor glitches. Older pv_ops (f.e. debian 2.6.32) have some
> >>>>more major issues.
> >>>what glitches should one expect with 3.0+, and having the choice,
> >>>would it be better to go with 3.1 or even 3.2?
> >>Right now I know about two of them:
> >>When you set up memory for virtual machine using xenballon, value in
> >>dom0 differ from value in domU. The issue is that -xen kernels 'hide'
> >>some memory in 'used' memory, and pv-ops just reducing TotalMem to value
> >>without that memory. Practically that means if you set up memory for
> >>domain to 2GiB client will saw only 1.95GiB and so on.
> >This really makes no practical difference.  The memory is "used" is
> >either case and the different reporting is a side-effect of the change
> >in how certain memory allocations are done.

David,

You are thinking that this is the vmalloc vs kmalloc memory for the
frontends?

> Well... For us it make HUGE difference. We running cloud with very 
> precise accounting of  fast automaric memory allocation for customer's 
> domains and we account them for ... em... KiB*hr value, so if we account 
> domains based on xc.get_domain_memkb value and customers saw difference 
> between TotalMem and our values this will make them feel like we 
> cheating. We not greedy and ready to 'cut' our mem_kb value to their 
> TotalMem, but I hasn't found any formula for that (calculate TotalMem 
> from static-max and dom_kb values) and I can't trust any data from 
> customer's domains (except request for memory we accept, serve and 
> happily take money for 'more memory').
> 
> It sounds ridiculous, but we avoiding pv_ops kernels usage due that 
> little ~50Mb steal. We stuck with -xen kernels (forward porting from 
> SUSE and native CentOS 2.6.18-xen). I don't know what we will do in the 
> future, but right now PV-ops is not good...

50MB is rather a large amount - it should be more of a couple of MBs -
unless there are other things in the picture (P2M? per-cpu?). Have you
tried to run the same kernel version but different architecture - so a
SuSE 2.6.X kernel with a pvops 2.6.X, where X=X? If so, were there any
obvious disreprancies in the e820 and in the "Memory reserved" values?
Were the .config similar?


_______________________________________________
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®.