From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: vram_dirty vs. shadow paging dirty tracking Date: Wed, 14 Mar 2007 11:00:17 -0500 Message-ID: <45F81C11.1020404@us.ibm.com> References: <45F6FC68.3040207@us.ibm.com> <20070314082210.GX12238@edwin-srv.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070314082210.GX12238@edwin-srv.sh.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Zhai, Edwin" Cc: Ian Pratt , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Zhai, Edwin wrote: > On Tue, Mar 13, 2007 at 02:32:56PM -0500, Anthony Liguori wrote: > >> When thinking about multithreading the device model, it occurred to me >> that it's a little odd that we're doing a memcmp to determine which >> portions of the VRAM has changed. Couldn't we just use dirty page >> > > we made this code to improve the user vnc responsiveness long before. > now QEMU has new vnc implementation to resolve this issue and this code > introduce perf drop for guest of linux with X or windows. > Compared to what, just updating the full screen 30 times a second? I suspect that's not as bad as it sounds since SDL will be using a XShmImage. The VNC minimization is done based on a timer however so sticking the timer stuff into a thread is still useful. Of course, we should be able to quickly determine how useful this is by just changing SDL to update the whole image... Regards, Anthony Liguori > so i'd like to send a patch to revert it and make a proper solution in future. > > thanks, > > >> tracking in the shadow paging code? That should significantly lower the >> overhead of this plus I believe the infrastructure is already mostly >> there in the shadow2 code. >> >> Is this a sane idea? >> >> Regards, >> >> Anthony Liguori >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> > >