From mboxrd@z Thu Jan 1 00:00:00 1970 From: david ahern Subject: Re: KVM Test result, KVM62-RC2 Date: Wed, 27 Feb 2008 07:22:32 -0700 Message-ID: <47C57228.7000507@cisco.com> References: <10EA09EFD8728347A513008B6B0DA77A02D3B6A3@pdsmsx411.ccr.corp.intel.com> <47C3FEE5.90209@bppiac.hu> <1204027963.20221.0.camel@localhost.localdomain> <47C40FEE.3080603@bppiac.hu> <47C41673.702@bppiac.hu> <20080227045339.GA5159@dmt> <47C53773.8080603@bppiac.hu> <20080227140013.GA13385@dmt> <47C56D4D.7090103@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity , Marcelo Tosatti Return-path: In-Reply-To: <47C56D4D.7090103@qumranet.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org I'm the 'dsahern' in the bug report (that's my sourceforge login). Per the thread below yes it is due to networking and as recently as 3 days ago it made a bit of difference for Arne Kepp with his Centos 5 VM. david Avi Kivity wrote: > Marcelo Tosatti wrote: >> On Wed, Feb 27, 2008 at 11:12:03AM +0100, Farkas Levente wrote: >> >>>> You can workaround these problems by using a different, less problematic >>>> clocksource such as acpipm, until the TSC/migration issues are fully >>>> resolved. >>>> >>>> Add "clocksource=acpi_pm" to the kernel options. >>>> >>> than just quck question we use the noapic kernel option for the guest (i >>> don't remember why but there was some problem without it about half year >>> ago). do i still have to use the noapic option for the kernel? (i hope >>> somebody remember the reason:-) >>> >> Apparently dsahern found that the noapic option fixed or alleviated >> rtl8139 problems under high traffic: >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=1802082&group_id=180599&atid=893831 >> >> > > I've just run several hours with noapic to confirm. > >> I don't know details of the problem or why noapic made a difference. >> > > Seems to point the finger at the ioapic code. Could be because the load > is lower with pic, though. > > I've looked at the ioapic locking and it seems fine. > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/