From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LREMg-0004oY-Hd
	for qemu-devel@nongnu.org; Sun, 25 Jan 2009 18:26:06 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LREMe-0004mA-Or
	for qemu-devel@nongnu.org; Sun, 25 Jan 2009 18:26:05 -0500
Received: from [199.232.76.173] (port=36228 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LREMe-0004lx-Jv
	for qemu-devel@nongnu.org; Sun, 25 Jan 2009 18:26:04 -0500
Received: from mx20.gnu.org ([199.232.41.8]:4224)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1LREMe-0005iV-CJ
	for qemu-devel@nongnu.org; Sun, 25 Jan 2009 18:26:04 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1LREMd-0000RB-76
	for qemu-devel@nongnu.org; Sun, 25 Jan 2009 18:26:03 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [6391] Fix nographic mode and VNC
Date: Sun, 25 Jan 2009 23:25:58 +0000
References: <E1LPikI-0005cS-RK@cvs.savannah.gnu.org>
	<200901231820.32999.paul@codesourcery.com>
	<20090125195722.GC4799@shareable.org>
In-Reply-To: <20090125195722.GC4799@shareable.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200901252325.59905.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>

On Sunday 25 January 2009, Jamie Lokier wrote:
> Paul Brook wrote:
> > Maybe. You risk having to put an SMP safe lock in the MMIO handler, which
> > would probably do bad things to performance.
>
> Would it?  It's just one atomic operation in the non-contention case,
> and MMIO writes could be queued the same way that KVM queues them,
> without needing locks for each individual op.

Depends on the host. Even in the uncontended case grabbing a lock tends to 
require fairly strong memory barriers.

Like I said, kvm already exhibits fairly abysmal performance characteristics 
in this area. I'm not sure how much write coalescing actually helps in 
practice for anything other than VGA. It certainly doesn't help with reads.

Paul