From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: KVM lock contention on 48 core AMD machine
Date: Mon, 21 Mar 2011 20:53:34 +0200
Message-ID: <4D879EAE.60301@redhat.com>
References: <AANLkTikZZ4MXZjx_+6u-vKVSgxULQo2BkQKRO6K_vzFy@mail.gmail.com>	 <20110318123031.GB6066@8bytes.org>	 <AANLkTin2k1ZSLa0NG6pKBvHYnKEV21t8pEqzeJWNn_rR@mail.gmail.com>	 <4D871F6C.40207@redhat.com>	 <AANLkTintxnKRQ4rD4Wo8_MHU4yJVzYaRhR=GjnDMGwNj@mail.gmail.com>	 <AANLkTin8ZoUAVR2ajoV6cBFiUSe_Dof0_k60dcAGW3r-@mail.gmail.com>	 <4D875842.9050308@redhat.com>	 <AANLkTikWQS281kTtJ32-qo5U+w_BAak7qUwVhUQgOxxv@mail.gmail.com>	 <4D8773AA.8030408@redhat.com>	 <AANLkTin3Si1EAa=Va6f45vW-tYQ1Yk8dETXpHJHHHkxe@mail.gmail.com>	 <1300726498.2884.493.camel@edumazet-laptop>  <4D8784A9.8040303@redhat.com> <1300727545.2884.513.camel@edumazet-laptop> <4D879D73.2090608@msgid.tls.msk.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Eric Dumazet <eric.dumazet@gmail.com>, ben@iagu.net,
	KVM list <kvm@vger.kernel.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:11747 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751494Ab1CUSx4 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 21 Mar 2011 14:53:56 -0400
In-Reply-To: <4D879D73.2090608@msgid.tls.msk.ru>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 03/21/2011 08:48 PM, Michael Tokarev wrote:
> 21.03.2011 20:12, Eric Dumazet wrote:
> >  Le lundi 21 mars 2011 =C3=A0 19:02 +0200, Avi Kivity a =C3=A9crit =
:
> >
> >>  Any ideas on how to fix it?  We could pre-allocate IDs and batch =
them in
> >>  per-cpu caches, but it seems like a lot of work.
> >>
> >
> >  Hmm, I dont know what syscalls kvm do, but even a timer_gettime() =
has to
> >  lock this idr_lock.
>
> I wonder why my testcase - 160 kvm guests on a 2-core AMD AthlonII CP=
U -
> shows no contention of that sort, not at all...  Yes sure, all these
> (linux) guests are idling at login: prompt, but I'd expect at least
> some gettimeofday() and some load average, -- everything stays close
> to zero.

=46or this workload spinlock contention only happens on large machines;=
 it=20
(mostly) doesn't matter how many guests you have on a small host.

--=20
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.