qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: vans163 <vans_163@yahoo.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1618122] Re: qemu-monitor screendump very slow
Date: Mon, 29 Aug 2016 18:55:16 -0000	[thread overview]
Message-ID: <20160829185517.15620.5530.launchpad@soybean.canonical.com> (raw)
In-Reply-To: 20160829160030.27613.81837.malonedeb@gac.canonical.com

** Description changed:

  qemu-monitor screendump often using 10-20% cpu usage of one core to take
  a small capture.
  
  Most of the CPU usage seems to come from libpixman. There were many
  reports of libpixman becoming 8 times slower in newer releases.
  
  https://github.com/qemu/qemu/blob/0c56c6ab68902281094c7aac6305e2321c34c187/ui/console.c#L285
  
  Simple Valgrind Ir report.
  
  --------------------------------------------------------------------------------
-             Ir
+            Ir 
  --------------------------------------------------------------------------------
- 56,592,286,124  PROGRAM TOTALS
+ 9,994,313,959  PROGRAM TOTALS
  
  --------------------------------------------------------------------------------
-             Ir  file:function
+            Ir  file:function
  --------------------------------------------------------------------------------
- 40,288,379,712  ???:0x000000000000caa0 [/usr/lib64/libpixman-1.so.0.34.0]
-  3,585,795,168  ???:0x000000000006df20 [/usr/lib64/libpixman-1.so.0.34.0]
-  1,763,982,432  ???:0x0000000000052360 [/usr/lib64/libpixman-1.so.0.34.0]
-  1,517,832,033  ???:__memcpy_sse2_unaligned [/usr/lib64/libc-2.23.so]
-    993,997,885  ???:__GI_mempcpy [/usr/lib64/libc-2.23.so]
-    484,059,456  ???:0x0000000000050430 [/usr/lib64/libpixman-1.so.0.34.0]
-    460,109,168  ???:pixman_image_composite32 [/usr/lib64/libpixman-1.so.0.34.0]
+ 4,883,603,360  /usr/src/debug/pixman-0.34.0/pixman/pixman-access.c:store_scanline_b8g8r8 [/usr/lib64/libpixman-1.so.0.34.0]
+   282,312,800  /usr/src/debug/pixman-0.34.0/pixman/pixman-implementation.c:_pixman_implementation_iter_init [/usr/lib64/libpixman-1.so.0.34.0]
+   267,394,160  /usr/src/debug/pixman-0.34.0/pixman/pixman-sse2.c:sse2_fetch_x8r8g8b8 [/usr/lib64/libpixman-1.so.0.34.0]
+   256,761,600  /usr/src/debug/pixman-0.34.0/pixman/pixman-private.h:store_scanline_b8g8r8
+   254,676,199  ???:0x0000000000011f40 [/usr/lib64/libjemalloc.so.2]
+   199,990,526  ???:0x0000000000011a10 [/usr/lib64/libjemalloc.so.2]
  
- I tried taking a look on how to fix this, but it seems pixman is deeply
- enrooted inside the monitor.  I wanted to try to simply take whats on
- the display and memcpy it into .ppm format manually creating the file
- header, but I cant figure out where the raw display buffer/image is
- gotten from.
+ 
+ I tried taking a look on how to fix this, but it seems pixman is deeply enrooted inside the monitor.  I wanted to try to simply take whats on the display and memcpy it into .ppm format manually creating the file header, but I cant figure out where the raw display buffer/image is gotten from.
  
  For example this is DisplaySurface:
  
  struct DisplaySurface {
      pixman_format_code_t format;
      pixman_image_t *image;
      uint8_t flags;
  #ifdef CONFIG_OPENGL
      GLenum glformat;
      GLenum gltype;
      GLuint texture;
  #endif
  };
  
  Which as you can see already has the pixman_image_t. Maybe I should just
  work with that pixman_image_t?
  
  The most effective solution IMO seems to just memcpy from the display
  into a premade header for a .ppm or .bmp file assuming 24 or 32 bpp. No
  need for libpixman.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1618122

Title:
  qemu-monitor screendump very slow

Status in QEMU:
  New

Bug description:
  qemu-monitor screendump often using 10-20% cpu usage of one core to
  take a small capture.

  Most of the CPU usage seems to come from libpixman. There were many
  reports of libpixman becoming 8 times slower in newer releases.

  https://github.com/qemu/qemu/blob/0c56c6ab68902281094c7aac6305e2321c34c187/ui/console.c#L285

  Simple Valgrind Ir report.

  --------------------------------------------------------------------------------
             Ir 
  --------------------------------------------------------------------------------
  9,994,313,959  PROGRAM TOTALS

  --------------------------------------------------------------------------------
             Ir  file:function
  --------------------------------------------------------------------------------
  4,883,603,360  /usr/src/debug/pixman-0.34.0/pixman/pixman-access.c:store_scanline_b8g8r8 [/usr/lib64/libpixman-1.so.0.34.0]
    282,312,800  /usr/src/debug/pixman-0.34.0/pixman/pixman-implementation.c:_pixman_implementation_iter_init [/usr/lib64/libpixman-1.so.0.34.0]
    267,394,160  /usr/src/debug/pixman-0.34.0/pixman/pixman-sse2.c:sse2_fetch_x8r8g8b8 [/usr/lib64/libpixman-1.so.0.34.0]
    256,761,600  /usr/src/debug/pixman-0.34.0/pixman/pixman-private.h:store_scanline_b8g8r8
    254,676,199  ???:0x0000000000011f40 [/usr/lib64/libjemalloc.so.2]
    199,990,526  ???:0x0000000000011a10 [/usr/lib64/libjemalloc.so.2]

  
  I tried taking a look on how to fix this, but it seems pixman is deeply enrooted inside the monitor.  I wanted to try to simply take whats on the display and memcpy it into .ppm format manually creating the file header, but I cant figure out where the raw display buffer/image is gotten from.

  For example this is DisplaySurface:

  struct DisplaySurface {
      pixman_format_code_t format;
      pixman_image_t *image;
      uint8_t flags;
  #ifdef CONFIG_OPENGL
      GLenum glformat;
      GLenum gltype;
      GLuint texture;
  #endif
  };

  Which as you can see already has the pixman_image_t. Maybe I should
  just work with that pixman_image_t?

  The most effective solution IMO seems to just memcpy from the display
  into a premade header for a .ppm or .bmp file assuming 24 or 32 bpp.
  No need for libpixman.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1618122/+subscriptions

  parent reply	other threads:[~2016-08-29 19:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-29 16:00 [Qemu-devel] [Bug 1618122] [NEW] qemu-monitor screendump very slow vans163
2016-08-29 17:39 ` [Qemu-devel] [Bug 1618122] " vans163
2016-08-29 18:55 ` vans163 [this message]
2016-08-29 19:01 ` vans163
2016-08-31 12:53 ` vans163
2021-04-22  5:21 ` Thomas Huth
2021-06-22  4:17 ` Launchpad Bug Tracker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160829185517.15620.5530.launchpad@soybean.canonical.com \
    --to=vans_163@yahoo.com \
    --cc=1618122@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).