unity8-dash has a thread that is polling rather rapidly on epoll wait

scopes_ng:: is most probably unity-scopes-shell

Yeah, this is between -api (most probably there - zmq) and -shell.

In 60 seconds, one can observe:

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 44.51 2.250000 2139 1052 poll
 28.03 1.416574 366 3871 epoll_wait
 24.33 1.230000 10250 120 rt_sigtimedwait
  2.77 0.140000 70000 2 restart_syscall
  0.26 0.013026 2 6306 fcntl64
  0.04 0.002036 1 3153 3153 connect
  0.01 0.000655 0 3213 close
  0.01 0.000607 0 3213 socket
  0.01 0.000529 0 7134 clock_gettime
  0.01 0.000520 1 1026 write
  0.01 0.000352 0 1038 16 read
  0.00 0.000246 0 985 recvfrom
  0.00 0.000098 1 120 madvise
  0.00 0.000000 0 54 ioctl
  0.00 0.000000 0 6 gettimeofday
  0.00 0.000000 0 120 clone
  0.00 0.000000 0 25 mprotect
  0.00 0.000000 0 1 writev
  0.00 0.000000 0 1 sched_yield
  0.00 0.000000 0 120 rt_sigprocmask
  0.00 0.000000 0 15 5 futex
  0.00 0.000000 0 6 bind
  0.00 0.000000 0 6 getsockname
  0.00 0.000000 0 12 sendto
  0.00 0.000000 0 77 13 recvmsg
  0.00 0.000000 0 120 set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00 5.054643 31796 3187 total

The 3153 failed connects are to named sockets that don't exist. That's a rate of 52 PER SECOND. This is rather ridiculous, we are meant to be trying to make a low power phone last and not drain the battery on this kind of rapid polling.

This is caused by Zmq retrying behind the scenes. There are ways to mitigate this, but I'd like to learn a bit more first, if possible. Can you tell me how I can reproduce this and what you did to the phone before you noticed the problem? Install or uninstall scopes or similar?

Test scenario:

Clean install with developer mode so I can access the device via adb shell. Device is on the lock screen, sitting idle, so essentially is should be doing not a lot.

I ran eventstat to see which processes are generating the most wakeups:

root@ubuntu-phablet:~# eventstat 60 1
 Event/s PID Task Init Function Callback
   87.00 0 [swapper/0] hrtimer_start_range_ns tick_sched_timer
   39.05 3759 scopes_ng::Scop hrtimer_start_range_ns hrtimer_wakeup
   16.68 5 [kworker/u:0] hwmsen_work_func hwmsen_poll
   10.00 3951 ubuntu-location hrtimer_start_range_ns hrtimer_wakeup

Then I strace'd PID 3759,
strace -p 3759 -e connect

Thanks for the info! The linked branch mitigates this be eliminating reconnects for twoway invocations completely, and limiting reconnection attempts for oneway invocations to at most one per second. This is an interim fix, and I'm working on a solution that will eliminate the reconnection attempts completely once they have failed a number of times, but that's a non-trivial change. For now, this will certainly help to reduce battery drain by a lot.

Great! Thanks!

Thanks for the heads-up! This would have gone unnoticed for a long time without your diligence!