From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: slow guest performance with build load, looking for ideas Date: Mon, 29 Jun 2009 00:28:10 +0300 Message-ID: <4A47E06A.7040700@redhat.com> References: <20090612210443.GA21840@sgi.com> <4A34C3D2.9020009@redhat.com> <20090618230744.GA19307@sgi.com> <4A477B8C.2010502@redhat.com> <20090628190500.GA7347@sgi.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: Erik Jacobson Return-path: Received: from mx2.redhat.com ([66.187.237.31]:45659 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751906AbZF1V14 (ORCPT ); Sun, 28 Jun 2009 17:27:56 -0400 In-Reply-To: <20090628190500.GA7347@sgi.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/28/2009 10:05 PM, Erik Jacobson wrote: >>> * In some of the timing runs on this system, the "real time" reported by >>> the time command was off by 10 to 11 times. Issues were found in >>> the messages file that seemed to relate to this including HUGE time >>> adjustments by NTP and kernel hrtimer 'interrupt too slow' messages. >>> This specific problem seems to be intermittent. >>> >> This is on the host? It can easily ruin your day. >> > > This was in the guest. > Ok. Please keep ntp off in the guest and verify the guest says it uses kvmclock. >> Can you post kvm_stat output during the run? >> > > Sure, I'll try to get time on the system again next week and post in > to the thread again. We'll still have the issue with the non-sequential > nodes and incorrect representation of memory for this two-socket > Nehalem system. I don't think that patch has made it in to the kernel. > > Thanks for replying back. > > If you have any other things you'd suggest trying, I'm game to give it a > whirl. Someone suggested trying to export a whole PCI device to the guest. > I won't be able to do that on this machine, maybe later when I have physical > access to the system. Besides, that exercise might not poke at what I'm > interested in anyway. > Shouldn't be needed. It's sufficient to export an LVM volume with cache=none: -drive file=/dev/vg/lv,cache=none,if=virtio > Others suggested some potential settings EPT (Extended Page Table) and > VPID (Virtual Path Identifier?) but I don't see where these settings are > exposed (they aren't, for example, in this system's BIOS). > Look in /sys/modules/kvm_intel/paramters, ept and vpid should default to enabled. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.