All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] 100% host cpu with gtk3
@ 2018-06-06 10:43 Fam Zheng
  2018-06-06 11:37 ` Gerd Hoffmann
  2018-06-06 11:37 ` Daniel P. Berrangé
  0 siblings, 2 replies; 3+ messages in thread
From: Fam Zheng @ 2018-06-06 10:43 UTC (permalink / raw)
  To: qemu-devel; +Cc: kraxel

Hi Gerd,

When using the gtk frontend, it seems there is a busy loop in libgtk repeatedly
calling recvmsg, causing 100% cpu on the main thread. This started to appear
after I upgraded to Fedora 28. Is this a known problem?

Any hints on how to track it down?

Fam

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] 100% host cpu with gtk3
  2018-06-06 10:43 [Qemu-devel] 100% host cpu with gtk3 Fam Zheng
@ 2018-06-06 11:37 ` Gerd Hoffmann
  2018-06-06 11:37 ` Daniel P. Berrangé
  1 sibling, 0 replies; 3+ messages in thread
From: Gerd Hoffmann @ 2018-06-06 11:37 UTC (permalink / raw)
  To: Fam Zheng; +Cc: qemu-devel

On Wed, Jun 06, 2018 at 06:43:57PM +0800, Fam Zheng wrote:
> Hi Gerd,
> 
> When using the gtk frontend, it seems there is a busy loop in libgtk repeatedly
> calling recvmsg, causing 100% cpu on the main thread. This started to appear
> after I upgraded to Fedora 28. Is this a known problem?

No, didn't saw this (but running rhel-7 on my workstation).

> Any hints on how to track it down?

perf top, maybe with with call graphs would be the first thing I
would try ...

cheers,
  Gerd

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] 100% host cpu with gtk3
  2018-06-06 10:43 [Qemu-devel] 100% host cpu with gtk3 Fam Zheng
  2018-06-06 11:37 ` Gerd Hoffmann
@ 2018-06-06 11:37 ` Daniel P. Berrangé
  1 sibling, 0 replies; 3+ messages in thread
From: Daniel P. Berrangé @ 2018-06-06 11:37 UTC (permalink / raw)
  To: Fam Zheng; +Cc: qemu-devel, kraxel

On Wed, Jun 06, 2018 at 06:43:57PM +0800, Fam Zheng wrote:
> Hi Gerd,
> 
> When using the gtk frontend, it seems there is a busy loop in libgtk repeatedly
> calling recvmsg, causing 100% cpu on the main thread. This started to appear
> after I upgraded to Fedora 28. Is this a known problem?
> 
> Any hints on how to track it down?

GLib has systemtap probes registered in its dispatch code. These probes
will include the name of the GSource. You could possibly use this to
identify which GSource is firing too often.

eg in gmain.c in glib code there are these events to hook into:

          TRACE (GLIB_MAIN_BEFORE_DISPATCH (g_source_get_name (source), source,
                                            dispatch, callback, user_data));
          need_destroy = !(* dispatch) (source, callback, user_data);
          TRACE (GLIB_MAIN_AFTER_DISPATCH (g_source_get_name (source), source,
                                           dispatch, need_destroy));



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-06-06 11:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-06 10:43 [Qemu-devel] 100% host cpu with gtk3 Fam Zheng
2018-06-06 11:37 ` Gerd Hoffmann
2018-06-06 11:37 ` Daniel P. Berrangé

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.