didon eats up CPU power

Bug #1871008 reported by Christoph Anton Mitterer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Diodon
Fix Released
High
Unassigned

Bug Description

Hi.

Just noted that, even though not used, diodon eats up quite some CPU power, like 120mW or so all the time.

Attaching to it with strace it seems to constantly poll some resource, and always getting errors on it.

Any ideas?

Cheers,
Chris.

Revision history for this message
Oliver Sauder (sao) wrote :

I haven't experienced this behaviour on my machine before, maybe it is something in the clipboard history which causes this.

For better analysis some debug information will be helpful.

Kill all Diodon processes and then run following command:

G_MESSAGES_DEBUG=all diodon > diodon_debug.log 2>&1

Let Diodon run a little bit, make some copy and paste actions and observe whether the CPU issue remains. If yes close Diodon and attach diodon_debug.txt to this issue.

Revision history for this message
Christoph Anton Mitterer (calestyo) wrote :

Hey.

Sorry for the delay in replying, but noticing the energy consumption of diodon was actually just a side product of me trying to trace down some much more serious problems with CPU temperature increase ([0] and [1]).

I've had tried clearing the history, but I don't think this changes anything.

Right now I've just did a fresh start of diodon with debug output, and even though it's not active (i.e. the menu of it) and I do not mark/select/copy anything, top shows:
    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   6314 calestyo 20 0 649468 28616 20120 S 0,3 0,1 0:01.00 diodon

The CPU utilisation actually varies, sometimes it's 0%... but it also goes up to 0,7%... but usually it's 0,3%.

If I do mark/select something it will go up noticeably... like 6-8% usage.
But even when doing nothing, not even moving the mouse pointer or typing anything it's always around 0,3%

Looking at it from powertop (again, when I don't use it or select something or so):
Power est. Usage Events/s Category Description
...
  110 mW 3,1 ms/s 27,4 Process [PID 6314] diodon
...

It's always around 100-115 mW.

Attached is also the log as you wanted.

Cheers,
Chris.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=207245
[1] https://gitlab.freedesktop.org/drm/intel/-/issues/953

Revision history for this message
Christoph Anton Mitterer (calestyo) wrote :
Download full text (14.5 KiB)

When you attach strace to diodon, do you also see a constant and rather fast flow of these:

strace: Process 6592 attached
restart_syscall(<... resuming interrupted read ...>) = 0
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 3, 2) = 0 (Timeout)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\22\0\7\0\2\0\340\0035\2\0\0005\2\0\0\10\0\0\0\1\0\0\0a\0\2\0", iov_len=28}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 28
poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0e\16\2\0\340\0035\2\0\0G\204J\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\27\0\2\0\1\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0f\16\0\0\0\0\2\0\200\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\30\0\6\0\2\0\340\3\1\0\0\0006\2\0\0\230\1\0\0G\204J\0", iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 3, 484) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0g\16\2\0\340\3\230\1\0\0H\204J\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 3, 0) = 0 (Timeout)
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\24\0\6\0\2\0\340\3\230\1\0\0\0\0\0\0\0\0\0\0\377\377\377\37", iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
poll([{fd=7, events=POLLIN}], 1, -1) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\10h\16\1\0\0\0006\2\0\0\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 36
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x55add9016cb0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\23\0\3\0\2\0\340\3\230\1\0\0\203-\2\0\0\0\0\0", iov_len=20}...

Revision history for this message
Oliver Sauder (sao) wrote :

When looking at the strace and debug infos I had one other idea.

Do you have 'Use primary selection' enabled in your Diodon preferences? If yes could you disable this option and check again whether this solves the CPU usage issue?

Revision history for this message
Christoph Anton Mitterer (calestyo) wrote :

Yes, this in fact solves power usage and CPU utilisation.

So... anything that can be done about it (except disabling the option)?

Revision history for this message
Oliver Sauder (sao) wrote :

This is actually a very old issue (https://esite.ch/2012/04/saving-power-with-diodon-0-8-0/) when using primary selection clipboard GTK didn't trigger owner-change signal https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html#GtkClipboard-owner-change

A workaround to this was to run a timer which periodically checks the primary selection clipboard. That's why you see the high CPU utilisation.

As this has been a while back I have now tested it again and it actually seems to work now with newer GTK versions without the timer.

A patch is in the making https://github.com/diodon-dev/diodon/pull/22

Revision history for this message
Christoph Anton Mitterer (calestyo) wrote :

Great :-)

Will be good to see a fixed version coming out :-)

Oliver Sauder (sao)
Changed in diodon:
status: New → Fix Committed
importance: Undecided → High
milestone: none → 1.10.0
Revision history for this message
Oliver Sauder (sao) wrote :

A fix is committed to https://github.com/diodon-dev/diodon

It can be build from source from there or it is also available in the daily ppa https://launchpad.net/~diodon-team/+archive/ubuntu/daily

The CPU power issue should certainly be solved as the timer is removed. What could be that there are some regression in terms of primary selection - Diodon now fully relies on GTK detecting those changes.

If you find time to testrun it that would be great. A new release with this and other fixes should come out in the next few days in case there are no critical issues.

Oliver Sauder (sao)
Changed in diodon:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.