From: Andrew Randrianasulu <randrianasulu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: qemu -display sdl,gl=on also eats CPU
Date: Mon, 17 Aug 2020 16:44:28 +0300 [thread overview]
Message-ID: <202008171644.28566.randrianasulu@gmail.com> (raw)
I rebuild mesa with debug symbols, and now top functions using CPU looks like this:
CPU: AMD64 family15h, speed 3800 MHz (estimated)
Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
-------------------------------------------------------------------------------
222978 45.1489 nouveau_dri.so nv50_bufctx_fence
222978 100.000 nouveau_dri.so nv50_bufctx_fence [self]
-------------------------------------------------------------------------------
150576 30.4889 libdrm_nouveau.so.2.0.0 /usr/X11R7/lib/libdrm_nouveau.so.2.0.0
150576 100.000 libdrm_nouveau.so.2.0.0 /usr/X11R7/lib/libdrm_nouveau.so.2.0.0 [self]
-------------------------------------------------------------------------------
39524 8.0029 libpixman-1.so.0.38.0 /usr/X11R7/lib/libpixman-1.so.0.38.0
39524 100.000 libpixman-1.so.0.38.0 /usr/X11R7/lib/libpixman-1.so.0.38.0 [self]
-------------------------------------------------------------------------------
28094 5.6885 libc-2.30.so memcpy
28094 100.000 libc-2.30.so memcpy [self]
-------------------------------------------------------------------------------
13758 2.7857 kallsyms dma_direct_alloc_pages
13758 100.000 kallsyms dma_direct_alloc_pages [self]
-------------------------------------------------------------------------------
2508 0.5078 qemu-system-x86_64 /usr/bin/qemu-system-x86_64
2508 100.000 qemu-system-x86_64 /usr/bin/qemu-system-x86_64 [self]
-------------------------------------------------------------------------------
1953 0.3954 ttm /ttm
1953 100.000 ttm /ttm [self]
-------------------------------------------------------------------------------
1661 0.3363 nouveau /nouveau
1661 100.000 nouveau /nouveau [self]
-------------------------------------------------------------------------------
1462 0.2960 kallsyms find_next_iomem_res
1462 100.000 kallsyms find_next_iomem_res [self]
-------------------------------------------------------------------------------
1355 0.2744 kvm_amd /kvm_amd
1355 100.000 kvm_amd /kvm_amd [self]
-------------------------------------------------------------------------------
1273 0.2578 kvm /kvm
1273 100.000 kvm /kvm [self]
-------------------------------------------------------------------------------
1208 0.2446 ld-2.30.so _dl_update_slotinfo
1208 100.000 ld-2.30.so _dl_update_slotinfo [self]
-------------------------------------------------------------------------------
1126 0.2280 kallsyms atomic_try_cmpxchg
1126 100.000 kallsyms atomic_try_cmpxchg [self]
-------------------------------------------------------------------------------
992 0.2009 libc-2.30.so cfree@GLIBC_2.0
992 100.000 libc-2.30.so cfree@GLIBC_2.0 [self]
-------------------------------------------------------------------------------
833 0.1687 libc-2.30.so malloc
833 100.000 libc-2.30.so malloc [self]
-------------------------------------------------------------------------------
810 0.1640 libc-2.30.so _int_free
810 100.000 libc-2.30.so _int_free [self]
-------------------------------------------------------------------------------
772 0.1563 kallsyms __x86_indirect_thunk_rax
772 100.000 kallsyms __x86_indirect_thunk_rax [self]
-------------------------------------------------------------------------------
CPU usage rose from 40% to 80% (at 1.4Ghz) over 6 hours of guest's uptime.
---------- Пересланное сообщение ----------
Тема: Re: [Nouveau] qemu -display sdl,gl=on also eats CPU
Дата: Понедельник 17 августа 2020
Отправитель: Andrew Randrianasulu <randrianasulu@gmail.com>
Получатель: Ilia Mirkin <imirkin@alum.mit.edu>, nouveau@lists.freedesktop.org
В сообщении от Monday 17 August 2020 08:09:37 вы написали:
> The DDX eating CPU isn't intrinsically bad. Did you check where perf
> says the CPU time is going? Could be doing copies/etc.
I think Xorg ended up eating ~13% CPU after I quit most programs, but it
was definitely better than much higher CPU usage before your patches.
I saw no additional debug messages in X log, so probably you covered
my specific case well.
qemu was eating CPU in nouveau_dri.so/libdrm_nouveau.so.2.0.0,
so I suspected something like 'too many error reports from vblanks'
may happen there, too.
Unfortunately, my standard build command for mesa included --strip,
so opreport -c was not giving any additional details ...
I just recompiled DDX again with if 0'ed debug message, will see how
it works alone, and then retry mesa build/qemu long-uptime testing ...
>
> On Mon, Aug 17, 2020 at 12:52 AM Andrew Randrianasulu
> <randrianasulu@gmail.com> wrote:
> >
> > I was testing Ilia's patches for ddx, and while they definitely helped for Xorg itself,
> > qemu still eats a lot of CPU if launched like this
> >
> > qemu-system-x86_64 -cdrom ~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 1G -display sdl,gl=on -enable-kvm
> >
> > and left for few hours.
> >
> > top - 07:38:01 up 18:05, 2 users, load average: 2,00, 1,89, 1,83
> > Tasks: 224 total, 3 running, 221 sleeping, 0 stopped, 0 zombie
> > %Cpu(s): 40,6 us, 6,1 sy, 0,3 ni, 49,2 id, 0,8 wa, 0,0 hi, 2,9 si, 0,0 st
> > MiB Mem : 11875,3 total, 3535,7 free, 3339,3 used, 5000,3 buff/cache
> > MiB Swap: 1145,0 total, 1131,2 free, 13,8 used. 4874,7 avail Mem
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 6215 guest 20 0 1455160 951768 45560 R 99,3 7,8 710:44.44 qemu-system-x86
> > 12655 guest 20 0 2459848 1,5g 126708 R 59,1 12,6 217:53.21 seamonkey
> > 1991 root 20 0 178112 109500 28840 S 20,9 0,9 187:20.05 Xorg
> > 2068 guest 20 0 104932 51660 30764 S 5,6 0,4 54:08.99 ktorrent
> > 6031 root 20 0 0 0 0 I 2,0 0,0 0:20.24 kworker/0:3-events
> > 3697 guest 20 0 382432 20308 13696 S 1,7 0,2 91:38.13 xmms
> > 2064 guest 20 0 55868 37048 23976 S 1,3 0,3 2:38.47 konsole
> > 2319 guest 20 0 40160 21248 18548 S 1,3 0,2 12:36.63 gkrellm
> > 5853 root 20 0 0 0 0 I 0,7 0,0 0:07.21 kworker/2:2-events
> >
> > opreport after operf --pid 6215 said:
> >
> > opreport
> > Using /home/guest/botva/src/xf86-video-nouveau/oprofile_data/samples/ for samples directory.
> > CPU: AMD64 family15h, speed 3800 MHz (estimated)
> > Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000
> > CPU_CLK_UNHALT...|
> > samples| %|
> > ------------------
> > 260163 100.000 qemu-system-x86_64
> > CPU_CLK_UNHALT...|
> > samples| %|
> > ------------------
> > 144120 55.3960 nouveau_dri.so
> > 87990 33.8211 libdrm_nouveau.so.2.0.0
> > 11783 4.5291 libpixman-1.so.0.38.0
> > 7884 3.0304 kallsyms
> > 5310 2.0410 libc-2.30.so
> > 689 0.2648 ld-2.30.so
> > 519 0.1995 nouveau
> > 501 0.1926 qemu-system-x86_64
> > 456 0.1753 ttm
> > 239 0.0919 kvm
> > 211 0.0811 kvm_amd
> > 81 0.0311 libpthread-2.30.so
> > 76 0.0292 drm
> > 49 0.0188 libSDL2-2.0.so.0.12.0
> > 43 0.0165 libxcb.so.1.1.0
> > 36 0.0138 libGL.so.1.2.0
> > 31 0.0119 libX11.so.6.3.0
> > 24 0.0092 snd_pcm
> > 23 0.0088 snd_hda_codec
> > 20 0.0077 libglib-2.0.so.0.5800.1
> > 11 0.0042 snd_timer
> > 9 0.0035 libglapi.so.0.0.0
> > 8 0.0031 libdrm.so.2.4.0
> > 7 0.0027 snd_aloop
> > 7 0.0027 snd_hda_intel
> > 7 0.0027 libxshmfence.so.1.0.0
> > 7 0.0027 libgcc_s.so.1
> > 5 0.0019 [vdso] (tgid:6215 range:0xf7f9f000-0xf7f9ffff)
> > 5 0.0019 snd_hda_core
> > 4 0.0015 r8169
> > 3 0.0012 libahci
> > 2 7.7e-04 ohci_hcd
> > 2 7.7e-04 libxcb-present.so.0.0.0
> > 1 3.8e-04 libatomic.so.1.1.0
> >
> > so, may be similar fix needed for mesa, too?
> >
> > ow, I started it in ddx src directory :} need to cleanup there. But at least data is 100
> >
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
-------------------------------------------------------
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
next reply other threads:[~2020-08-17 13:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 13:44 Andrew Randrianasulu [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-08-18 7:51 qemu -display sdl,gl=on also eats CPU Andrew Randrianasulu
2020-08-17 4:42 Andrew Randrianasulu
[not found] ` <202008170742.42032.randrianasulu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-17 5:09 ` Ilia Mirkin
[not found] ` <CAKb7UvghBJ46xD9u6MJEFvmbMYgZziq5sLQyRhZxVkVxcHZJqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-08-17 5:35 ` Andrew Randrianasulu
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=202008171644.28566.randrianasulu@gmail.com \
--to=randrianasulu-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.