From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 2/4] KVM: move coalesced_mmio locking to its own device Date: Tue, 26 May 2009 16:27:59 +0300 Message-ID: <4A1BEE5F.2000207@redhat.com> References: <20090520184841.954066003@localhost.localdomain> <20090520185134.623968425@localhost.localdomain> <4A195404.8040406@redhat.com> <20090525110403.GA2789@amt.cnet> <4A1BD171.5010908@redhat.com> <20090526131547.GB19383@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Gregory Haskins To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:42295 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751951AbZEZN2A (ORCPT ); Tue, 26 May 2009 09:28:00 -0400 In-Reply-To: <20090526131547.GB19383@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: >> >> Why not use slots_lock to protect the entire iodevice list (rcu one >> day), and an internal spinlock for coalesced mmio? >> > > Don't like using slots_lock to protect the entire iodevice list, its > reverse progress in my opinion. The PIO/MMIO device lists are data > structures used in hot path, they are not directly related to the > memslots, and therefore deserve a separate lock. Whenever slots_lock > becomes an issue, you'll have to entangle the mess, so better start > doing it now. > It's a reader/writer lock, so you'll never have contention. I'm okay with a new lock though. > Sure can switch to a internal spinlock for coalesced_mmio, but breaking > out if spin_trylock fails. You're OK with that? > Why not do a normal spin_lock()? It's not like you'll wait years for the store to complete. -- error compiling committee.c: too many arguments to function