From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call agenda for Feb 9 Date: Tue, 09 Feb 2010 08:18:47 -0600 Message-ID: <4B716EC7.1010900@codemonkey.ws> References: <20100209012851.GJ25751@x200.localdomain> <4B710714.1020109@redhat.com> <02FDE8B6-CCC9-4EA5-B7EB-6EFC6497C268@suse.de> <4B712249.4020703@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Graf , Avi Kivity , Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mail-iw0-f181.google.com ([209.85.223.181]:38835 "EHLO mail-iw0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754508Ab0BIOSw (ORCPT ); Tue, 9 Feb 2010 09:18:52 -0500 Received: by iwn11 with SMTP id 11so161002iwn.17 for ; Tue, 09 Feb 2010 06:18:49 -0800 (PST) In-Reply-To: <4B712249.4020703@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 02/09/2010 02:52 AM, Jan Kiszka wrote: > Alexander Graf wrote: > >> On 09.02.2010, at 07:56, Avi Kivity wrote: >> >>> - rcuify/fine-grain qemu locks >>> >> And this should be done either way, but is probably not a short-term goal. >> >> > Indeed. We won't get around this longterm as it is a scalability > bottleneck and a killer for RT guest load. We can't push everything into > the kernel. Qemu needs a smart plan how to gradually convert its CPU and > device model to fine-grained locking. > The VCPU loops should be easy to convert to lockless operation. It's easier to do this upstream but that requires a functioning IO thread. For the table based MMIO and PIO dispatch, RCU would be a good locking choice since these structures are rarely updated. The tricky bit is that the APIC has to be converted over to lockless before any other device can be converted because just about every device wants to inject an interrupt. Regards, Anthony Liguori > Jan > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeqvU-0005sY-Fr for qemu-devel@nongnu.org; Tue, 09 Feb 2010 09:18:52 -0500 Received: from [199.232.76.173] (port=40221 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeqvT-0005sH-U5 for qemu-devel@nongnu.org; Tue, 09 Feb 2010 09:18:51 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NeqvS-0006h1-KR for qemu-devel@nongnu.org; Tue, 09 Feb 2010 09:18:51 -0500 Received: from mail-iw0-f178.google.com ([209.85.223.178]:37629) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NeqvR-0006gu-U0 for qemu-devel@nongnu.org; Tue, 09 Feb 2010 09:18:50 -0500 Received: by iwn8 with SMTP id 8so1774117iwn.13 for ; Tue, 09 Feb 2010 06:18:49 -0800 (PST) Message-ID: <4B716EC7.1010900@codemonkey.ws> Date: Tue, 09 Feb 2010 08:18:47 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for Feb 9 References: <20100209012851.GJ25751@x200.localdomain> <4B710714.1020109@redhat.com> <02FDE8B6-CCC9-4EA5-B7EB-6EFC6497C268@suse.de> <4B712249.4020703@web.de> In-Reply-To: <4B712249.4020703@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Chris Wright , qemu-devel@nongnu.org, Alexander Graf , kvm@vger.kernel.org, Avi Kivity On 02/09/2010 02:52 AM, Jan Kiszka wrote: > Alexander Graf wrote: > >> On 09.02.2010, at 07:56, Avi Kivity wrote: >> >>> - rcuify/fine-grain qemu locks >>> >> And this should be done either way, but is probably not a short-term goal. >> >> > Indeed. We won't get around this longterm as it is a scalability > bottleneck and a killer for RT guest load. We can't push everything into > the kernel. Qemu needs a smart plan how to gradually convert its CPU and > device model to fine-grained locking. > The VCPU loops should be easy to convert to lockless operation. It's easier to do this upstream but that requires a functioning IO thread. For the table based MMIO and PIO dispatch, RCU would be a good locking choice since these structures are rarely updated. The tricky bit is that the APIC has to be converted over to lockless before any other device can be converted because just about every device wants to inject an interrupt. Regards, Anthony Liguori > Jan > >