Re: [PATCH] kvm tools, ui: Optimize SDL updates

[Sasha Levin <levinsasha928@gmail.com>]

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 <agraf@suse.de> 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.