From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM call agenda for Feb 9 Date: Tue, 09 Feb 2010 08:15:57 -0600 Message-ID: <4B716E1D.7000608@codemonkey.ws> References: <20100209012851.GJ25751@x200.localdomain> <4B710714.1020109@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-iw0-f181.google.com ([209.85.223.181]:34415 "EHLO mail-iw0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754451Ab0BIOQF (ORCPT ); Tue, 9 Feb 2010 09:16:05 -0500 Received: by iwn11 with SMTP id 11so156430iwn.17 for ; Tue, 09 Feb 2010 06:16:01 -0800 (PST) In-Reply-To: <4B710714.1020109@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/09/2010 12:56 AM, Avi Kivity wrote: > On 02/09/2010 03:28 AM, Chris Wright wrote: >> Please send in any agenda items you are interested in covering. > > hpet overhead on large smp guests > > I measured hpet consuming about a half a core's worth of cpu on an > idle Windows 2008 R2 64-way guest. This is mostly due to futex > contention, likely from the qemu mutex. > > Options: > - ignore, this is about 1% of the entire system (but overhead might > increase greatly if a workload triggers more hpet accesses) > - push hpet into kernel, with virtio-net, virtio-blk, and kernel-hpet, > there's little reason to exit into qemu Security, shamurity, let's just stick all of qemu in the kernel :-) > - rcuify/fine-grain qemu locks Should be pretty straight forward. It would start with removing the locking within kvm*.c such that qemu_mutex isn't acquired until we dispatch I/O operations. Then we can add lockless paths for dispatch as we convert device models over. Regards, Anthony Liguori