[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |