diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1618122')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1618122 | 79 |
1 files changed, 79 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1618122 b/results/classifier/zero-shot/108/other/1618122 new file mode 100644 index 000000000..f9cd5b0b9 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1618122 @@ -0,0 +1,79 @@ +other: 0.716 +graphic: 0.705 +semantic: 0.556 +device: 0.547 +performance: 0.540 +PID: 0.532 +files: 0.527 +permissions: 0.510 +debug: 0.486 +vnc: 0.464 +socket: 0.438 +network: 0.427 +KVM: 0.338 +boot: 0.308 + +qemu-monitor screendump very slow + +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 pixmap 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; +#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. + +Most of the CPU is coming from ppm_save(filename, surface, errp); + +graphic_hw_update(con) takes an insignificant amount. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + |