From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViUvF-00089I-Ow for qemu-devel@nongnu.org; Mon, 18 Nov 2013 14:55:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ViUv8-0004lG-U5 for qemu-devel@nongnu.org; Mon, 18 Nov 2013 14:55:49 -0500 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:59462 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViUv8-0004l3-1m for qemu-devel@nongnu.org; Mon, 18 Nov 2013 14:55:42 -0500 Message-ID: <528A70BA.9020002@kamp.de> Date: Mon, 18 Nov 2013 20:55:38 +0100 From: Peter Lieven MIME-Version: 1.0 References: <1384762641-18297-1-git-send-email-pl@kamp.de> <1384762641-18297-3-git-send-email-pl@kamp.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010109020409010300020000" Subject: Re: [Qemu-devel] [PATCH 2/3] ui/vnc: optimize dirty bitmap tracking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: corentincj@iksaif.net, Anthony Liguori , qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------010109020409010300020000 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Am 18.11.2013 17:27, schrieb Anthony Liguori: > > > On Nov 18, 2013 12:20 AM, "Peter Lieven" > wrote: > > > > vnc_update_client currently scans the dirty bitmap of each client > > bitwise which is a very costly operation if only few bits are dirty. > > vnc_refresh_server_surface does almost the same. > > this patch optimizes both by utilizing the heavily optimized > > function find_next_bit to find the offset of the next dirty > > bit in the dirty bitmaps. > > > > Signed-off-by: Peter Lieven > > > Can you include performance data? > I hoped that the checking 32bits (pipelined) at once compared to checking 32bits one-by-one would be convincing enough ;-) Do you have a special test in mind? Otherwise I could try to create an artificial test case with e.g. no bits dirty, all bits dirty, only a few bits dirty (cursor update) and compare the timing for both versions. Peter --------------010109020409010300020000 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit

Am 18.11.2013 17:27, schrieb Anthony Liguori:

On Nov 18, 2013 12:20 AM, "Peter Lieven" <pl@kamp.de> wrote:
>
> vnc_update_client currently scans the dirty bitmap of each client
> bitwise which is a very costly operation if only few bits are dirty.
> vnc_refresh_server_surface does almost the same.
> this patch optimizes both by utilizing the heavily optimized
> function find_next_bit to find the offset of the next dirty
> bit in the dirty bitmaps.
>
> Signed-off-by: Peter Lieven <pl@kamp.de>

Can you include performance data?

I hoped that the checking 32bits (pipelined) at once compared to
checking 32bits one-by-one would be convincing enough ;-)

Do you have a special test in mind? Otherwise I could try
to create an artificial test case with e.g. no bits dirty, all bits
dirty, only a few bits dirty (cursor update) and compare the
timing for both versions.

Peter
--------------010109020409010300020000--