From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH] kvm tools, ui: Optimize SDL updates Date: Sat, 04 Jun 2011 18:34:42 +0300 Message-ID: <1307201682.30165.0.camel@lappy> References: <1307136023-16693-1-git-send-email-penberg@kernel.org> <20110604095451.GA15349@elte.hu> <11EB6DEC-41E9-4C0A-A057-7E88EBA2A008@suse.de> <20110604104245.GF16292@elte.hu> <34B8A15A-AEF2-4E2D-99F5-0EDB41447C31@suse.de> <20110604105443.GH16292@elte.hu> <20110604115353.GA30593@elte.hu> <1307189056.7239.9.camel@lappy> <2707FA45-A5AA-4F95-8123-870FC59BF75B@suse.de> <1307197170.7239.11.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , Pekka Enberg , KVM list , Cyrill Gorcunov , John Floren , Gerd Hoffmann To: Alexander Graf Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:42458 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756750Ab1FDPet (ORCPT ); Sat, 4 Jun 2011 11:34:49 -0400 Received: by wya21 with SMTP id 21so1966379wya.19 for ; Sat, 04 Jun 2011 08:34:47 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Sat, 2011-06-04 at 17:21 +0200, Alexander Graf wrote: > On 04.06.2011, at 16:19, Sasha Levin wrote: > > > On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote: > >> On 04.06.2011, at 14:04, Sasha Levin wrote: > >> > >>> On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote: > >>>> * Alexander Graf wrote: > >>>> > >>>>> Why would you need panning/scrolling for a fast FB? It's really an > >>>>> optimization that helps a lot with VNC, but on local machines or > >>>>> SDL you shouldn't see a major difference. > >>>> > >>>> Qemu's fb console scrolling graphics is pretty slow to me even > >>>> locally so i assume that the dirty bitmap trick is not enough. > >>>> > >>>> VirtualBox graphics is very fast, but it probably has its own console > >>>> abstraction and scrolling/2D/3D acceleration. > >>>> > >>>> Also, since tools/kvm/ is really also about learning interesting > >>>> stuff, smooth scrolling was the historic first 'acceleration' usecase > >>>> that video graphics cards added - before they evolved more complex 2D > >>>> acceleration and then started doing 3D. > >>>> > >>>> Walking that path would allow us to do a gradual approach, while > >>>> still having relevant functionality and enhancements at every step. > >>>> > >>>>> Unless you use the FB as MMIO. Qemu just maps the FB as RAM and > >>>>> checks for dirty bitmap updates periodically. That way you don't > >>>>> constantly exit due to MMIO and are good on speed. The slowness you > >>>>> describe sounds a lot as if you don't do that trick. > >>>> > >>>> Correct, and i assumed we already do the dirty-bitmap trick: > >>>> > >>>> KVM_MEM_LOG_DIRTY_PAGES > >>>> KVM_GET_DIRTY_LOG > >>>> > >>>> But you are right, we do not actually do that! > >>>> > >>>> Pekka, i think this should be the next step. We'll need scrolling > >>>> after that ... > >>>> > >>>> In theory it would also be nice to tunnel the VGA text frame buffer > >>>> over to the KVM tool - as serial console is not supported by most > >>>> installers and default distro images. We could actually do a rather > >>>> good job of emulating it via Slang/Curses. > >>> > >>> I doubt we could use dirty pages because unless guest VESA driver > >>> supports panning, it will redraw the entire FB - which means that all > >>> pages will be dirty. > >> > >> Please recheck the math and compare 60 dirty bitmap checks+flushes per second to a few million MMIO exits for every single pixel :). > > > > I might be missing something here, but if every single pixel changes due > > to scrolling, doesn't it mean that all the pages will be marked as > > 'dirty' anyway? > > Sure, but you don't need to exit to user space for every single pixel, but instead process the whole thing asynchronously. Just run kvm_stat while running your current implementation and you'll pretty soon realize what I'm talking about :). I we use coalesced MMIO we only exit when the shared page is full. If we mark a memory region as log dirty we won't get MMIO exits on it? -- Sasha.