[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:
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.
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...

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.

Well... I post few weeks ago about problems with memory hotplug - I see this message in dmesg:

[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


 


Rackspace

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