WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops)

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops)
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Tue, 26 May 2009 22:41:02 +0300
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 26 May 2009 12:43:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <162f4c90-6431-4a2a-b337-6d7451d7b11e@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <162f4c90-6431-4a2a-b337-6d7451d7b11e@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Dan Magenheimer wrote:
It will also be interesting to see how far Xen can get along without real memory management (overcommit).

Several implementations of "classic" memory overcommit have been
done for Xen, most recently the Difference Engine work at UCSD.
It is true that none have been merged yet, in part because,
in many real world environments, "generalized" overcommit
often leads to hypervisor swapping, and performance becomes
unacceptable.  (In other words, except in certain limited customer
use models, memory overcommit is a "marketing feature".)

Swapping indeed drags performance down horribly. I regard it as a last resort solution used when everything else (page sharing, compression, ballooning, live migration) has failed. By having that last resort you can actually use the other methods without fearing an out-of-memory condition eventually.

Note that with SSDs disks have started to narrow the gap between memory and secondary storage access times, so swapping will actually start improving rather than regressing as it has done in recent times.

There's also a novel approach, Transcendent Memory (aka "tmem"
see http://oss.oracle.com/projects/tmem).  Though tmem requires the
guest to participate in memory management decisions (thus requiring
a Linux patch), system-wide physical memory efficiency may
improve vs memory deduplication, and hypervisor-based swapping
is not necessary.

Yes, I've seen that.  Another tool in the memory management arsenal.

The Linux scheduler already supports multiple scheduling classes. If we find that none of them will fit our needs, we'll propose a new one. When the need can be demonstrated to be real, and the implementation can be clean, Linux can usually be adapted.

But that's exactly George and Jeremy's point.  KVM will
eventually require changes that clutter Linux for purposes
that are relevant only to a hypervisor.

kvm has already made changes to Linux. Preemption notifiers allow us to have a lightweight exit path, and mmu notifiers allow the Linux mmu to control the kvm mmu. And in fact mmu notifiers have proven useful to device drivers.

It also works the other way around; for example work on cpu controllers will benefit kvm, and the real-time scheduler will also apply to kvm guests. In fact many scheduler and memory management features immediately apply to kvm, usually without any need for integration.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


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

<Prev in Thread] Current Thread [Next in Thread>