On Sat, 2011-06-04 at 17:40 +0200, Alexander Graf wrote: > On 04.06.2011, at 17:34, Sasha Levin wrote: > > > 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 <[email protected]> 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. > > Yes, which will be very often for full redrawing guests. Remember, we're > talking about megabytes of graphics data. Plus you still need to call your > internal MMIO handler for every single access then. And I hope I don't even > have to mention read performance (which is abysmal on real graphics cards too > though). > > > If we mark a memory region as log dirty we won't get MMIO exits on it? > > [..] If you mark a memory region as coalesced you also don't get MMIO exits > on it. [..] >
We get MMIO exits on it when the ring is full, which is pretty often with the graphics card. I'll try the dirty log method later tonight. I don't see anything about no exits in the documentation though - if it actually prevents MMIO exits to the region it should probably be documented. > $ while true; do echo -n x; done > > But I won't keep you from doing it. Implement it and see how it performs. > This whole project is about trying to find out what is fast for yourselves, > no? :) Just make sure to also implement the dirty log way so you can actually > compare the numbers. > > > Alex > -- Sasha. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
