[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] a ton of kernel issues
On 13.12.2011 17:17, David Vrabel wrote: 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').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. 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... Well... I post few weeks ago about problems with memory hotplug - I see this message in dmesg:The second issue is lack of support of 'pre-inflated balloon', means you can not set up memory-static-max to 2GiB, target to 1GiB and do 'memory grow' from 1 G to 2 G latter without VM reboot. -xen kernels allow this (up to memory-static-max limit).This should work if memory hotplug is enabled. It is also supported without memory hotplug but this requires that the tools supply a suitable memory map that covers the largest memory-static-max limit you wish to support. I'm not sure if the tools can do this yet. [1935380.223401] System RAM resource 18000000 - 27ffffff cannot be added[1935380.223414] xen_balloon: reserve_additional_memory: add_memory() failed: -17 I post about that: http://old-list-archives.xen.org/archives/html/xen-users/2011-11/msg00278.html _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |