Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram patch forperformance

["Christian Limpach" <christian.limpach@xxxxxxxxx>]

On 3/20/07, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> I punted on this one. :-) Christian wasn't sure about it either, hence it's
> not been checked in.
My main concern is that with the patch we will be doing the transform
from vga ram into the display memory everytime (vga_draw_line, some
versions are quite expensive) and I don't see how that could be faster
than doing the sse2 optimized compare and copy?

When you test this, are the displays active or not, i.e. is the
display changing a lot or are they at the screen saver?

Maybe if the SDL frontend notices that its window is obscured, it
should tell the rest of the code that a scan is not required...

Same for VNC...

   christian

>  -- Keir
>
> On 20/3/07 08:38, "Li, Xin B" <xin.b.li@xxxxxxxxx> wrote:
>
> > Keir, do you think this patch is OK?
> > -Xin
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> >> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Zhai, Edwin
> >> Sent: Friday, March 16, 2007 11:04 AM
> >> To: Keir Fraser
> >> Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx; Zhai, Edwin
> >> Subject: Re: [Xen-devel] [PATCH][HVM] remove qemu shadow_vram
> >> patch forperformance
> >>
> >> On Thu, Mar 15, 2007 at 10:50:13AM +0000, Keir Fraser wrote:
> >>>
> >>>
> >>>
> >>> On 15/3/07 03:30, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:
> >>>
> >>>> remove qemu shadow_vram patch and force a whole screen
> >> update each time for
> >>>> performance.
> >>>>
> >>>> W/O this patch, there is huge performance drop in HVM
> >> domain when adding other
> >>>> guest(windows or linux with xwindow).
> >>>>
> >>>> shadow_vram_revert.patch - revert the shadow_vram patch
> >>>> shadow_vram_force_update.patch - explictly redraw screen each time
> >>>
> >>> How can updating the whole screen 30 times a second be
> >> faster than the
> >>> memcmp() that we do currently?
> >>
> >> as far as i can tell, the bottle neck is that orig method does
> >> memcmp and memcpy
> >> byte by byte. furthermore, orig method can void a update by
> >> multiple memcmp only
> >> if all bytes are equal, which is in the minority.
> >>
> >> there is no doubt we need a vram dirty for qemu, but current
> >> one is not the
> >> best. we can make a new one in future by shadow or something else.
> >>
> >> thanks,
> >>
> >>>
> >>>  -- Keir
> >>>
> >>
> >> --
> >> best rgds,
> >> edwin
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> http://lists.xensource.com/xen-devel
> >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel