Public bug reported: 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 -------------------------------------------------------------------------------- 56,592,286,124 PROGRAM TOTALS -------------------------------------------------------------------------------- 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] 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. ** Affects: qemu Importance: Undecided Status: New ** 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 -------------------------------------------------------------------------------- - 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] + 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] - I tried taking a look on how to fix this, but it seems pixmap is deeply + 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 starts. For example this is DisplaySurface: struct DisplaySurface { - pixman_format_code_t format; - pixman_image_t *image; - uint8_t flags; + pixman_format_code_t format; + pixman_image_t *image; + uint8_t flags; #ifdef CONFIG_OPENGL - GLenum glformat; - GLenum gltype; - GLuint texture; + 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. ** 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 -------------------------------------------------------------------------------- 56,592,286,124 PROGRAM TOTALS -------------------------------------------------------------------------------- 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] 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 starts. + 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 -------------------------------------------------------------------------------- 56,592,286,124 PROGRAM TOTALS -------------------------------------------------------------------------------- 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] 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
