From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chegu Vinod Subject: Re: Performance of 40-way guest running 2.6.32-220 (RHEL6.2) vs. 3.3.1 OS Date: Mon, 16 Apr 2012 03:04:47 +0000 (UTC) Message-ID: References: <4F871D12.3060006@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from plane.gmane.org ([80.91.229.3]:50388 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750982Ab2DPDFF (ORCPT ); Sun, 15 Apr 2012 23:05:05 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SJcFT-0008Pw-Tj for kvm@vger.kernel.org; Mon, 16 Apr 2012 05:05:04 +0200 Received: from zccy01cs104.houston.hp.com ([15.211.201.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Apr 2012 05:05:03 +0200 Received: from chegu_vinod by zccy01cs104.houston.hp.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Apr 2012 05:05:03 +0200 Sender: kvm-owner@vger.kernel.org List-ID: Rik van Riel redhat.com> writes: > > On 04/11/2012 01:21 PM, Chegu Vinod wrote: > > > > Hello, > > > > While running an AIM7 (workfile.high_systime) in a single 40-way (or a single > > 60-way KVM guest) I noticed pretty bad performance when the guest was booted > > with 3.3.1 kernel when compared to the same guest booted with 2.6.32-220 > > (RHEL6.2) kernel. > > > For the 40-way Guest-RunA (2.6.32-220 kernel) performed nearly 9x better than > > the Guest-RunB (3.3.1 kernel). In the case of 60-way guest run the older guest > > kernel was nearly 12x better ! > > > Turned on function tracing and found that there appears to be more time being > > spent around the lock code in the 3.3.1 guest when compared to the 2.6.32- 220 > > guest. > > Looks like you may be running into the ticket spinlock > code. During the early RHEL 6 days, Gleb came up with a > patch to automatically disable ticket spinlocks when > running inside a KVM guest. > Thanks for the pointer. Perhaps that is the issue. I did look up that old discussion thread. > IIRC that patch got rejected upstream at the time, > with upstream developers preferring to wait for a > "better solution". > > If such a better solution is not on its way upstream > now (two years later), maybe we should just merge > Gleb's patch upstream for the time being? Also noticed a recent discussion thread (that originated from the Xen context) http://article.gmane.org/gmane.linux.kernel.virtualization/15078 Not yet sure if this recent discussion is also in some way related to the older one initiated by Gleb. Thanks Vinod