From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3) Date: Wed, 25 Jun 2008 12:51:00 +0300 Message-ID: <48621504.3040304@qumranet.com> References: <48054518.3000104@cisco.com> <480F546C.2030608@cisco.com> <481215DE.3000302@cisco.com> <20080428181550.GA3965@dmt> <4816617F.3080403@cisco.com> <4817F30C.6050308@cisco.com> <48184228.2020701@qumranet.com> <481876A9.1010806@cisco.com> <48187903.2070409@qumranet.com> <4826E744.1080107@qumranet.com> <4826F668.6030305@qumranet.com> <48290FC2.4070505@cisco.com> <48294272.5020801@qumranet.com> <482B4D29.7010202@cisco.com> <482C1633.5070302@qumranet.com> <482E5F9C.6000207@cisco.com> <482FCEE1.5040306@qumranet.com> <4830F90A.1020809@cisco.com> <4830FE8D.6010006@cisco.com> <48318E64.8090706@qumranet.com> <4832DDEB.4000100@qumranet.com> <4835EEF5.9010600@cisco.com> <483D391F.7050007@qumranet.com> <483EDCEE.6070307@cisco.com> <4841094A.8090507@qumranet.com> <484422EE.5090501@cisco.com> <4 847A5B8.6020503@qumranet.com> <48481250.6060005@cisco.com> <4849686E.8000402@qumranet.com> <4859DEA6.5010503@cisco.com> <485DF25E.6060400@qumranet.com> <485FAE94.4040001@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: "David S. Ahern" Return-path: Received: from il.qumranet.com ([212.179.150.194]:27326 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754309AbYFYJvD (ORCPT ); Wed, 25 Jun 2008 05:51:03 -0400 In-Reply-To: <485FAE94.4040001@cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: David S. Ahern wrote: > > RHEL3 is in Maintenance mode (for an explanation see > http://www.redhat.com/security/updates/errata/) which means performance > enhancement patches will not make it in. > > Scratch that idea, then. > Also, I'm going to be out of the office for a couple of weeks in July, > so I will need to put this aside until mid-August or so. I'll reevaluate > options then. > One thing I'm looking at is implementing out-of-sync like Xen, which looks like it will obsolete the entire emulate vs flood thing at the cost of making unshadowing a little more expensive and consuming more memory. See http://thread.gmane.org/gmane.comp.emulators.xen.devel/52557 (and 58, 59, 60). -- error compiling committee.c: too many arguments to function