From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/5] kvm: Batch writes to MMIO Date: Mon, 26 May 2008 16:43:26 +0300 Message-ID: <483ABE7E.9080203@qumranet.com> References: <1211532607137-git-send-email-Laurent.Vivier@bull.net> <483AA643.3040400@qumranet.com> <1211803838.3908.5.camel@frecb07144> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Laurent Vivier Return-path: Received: from il.qumranet.com ([212.179.150.194]:19105 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755367AbYEZNn3 (ORCPT ); Mon, 26 May 2008 09:43:29 -0400 In-Reply-To: <1211803838.3908.5.camel@frecb07144> Sender: kvm-owner@vger.kernel.org List-ID: Laurent Vivier wrote: > Le lundi 26 mai 2008 =C3=A0 15:00 +0300, Avi Kivity a =C3=A9crit : > =20 >> Laurent Vivier wrote: >> =20 >>> When kernel has to send MMIO writes to userspace, it stores them >>> in memory until it has to pass the hand to userspace for another >>> reason. This avoids to have too many context switches on operations >>> that can wait. >>> >>> =20 >>> =20 >> Looks good. The only issue I see is inconsistent naming. Sometimes= you=20 >> use delayed_mmio, sometimes batched_mmio, and there's a way-too-gene= ric=20 >> kvm_batch. Please stick to a single name throughout the code. >> =20 > > Which is your favorite ? > > =20 kvm_coalesced_mmio? :) >>> VGA text scroll=09 >>> host_state_reload 13280568 (6:15) 3608362 (4:42) -73% (-25%) >>> =20 >> This is probably better addressed by allowing the guest to write=20 >> directly to VRAM, like in the graphic modes. >> =20 > > Should I modify something in the patch ? > =20 No, but when we direct-map text-mode vga, this benchmark will be obsole= te. --=20 error compiling committee.c: too many arguments to function