[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1618122] [NEW] qemu-monitor screendump very slow
|
From: |
vans163 |
|
Subject: |
[Qemu-devel] [Bug 1618122] [NEW] qemu-monitor screendump very slow |
|
Date: |
Mon, 29 Aug 2016 16:00:30 -0000 |
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
- [Qemu-devel] [Bug 1618122] [NEW] qemu-monitor screendump very slow,
vans163 <=