touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

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.

** Branch linked: lp:~michihenning/unity-scopes-api/reconnect-fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1364464

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

Status in “unity-scopes-api” package in Ubuntu:
  In Progress
Status in “unity-scopes-shell” package in Ubuntu:
  Invalid
Status in “unity8” package in Ubuntu:
  Invalid

Bug description:
  one of the threads to unity8-dash is creating quite a few wakeups per
  second:

  # eventstat 60 1

   Event/s PID   Task            Init Function             Callback
     13.02  2812 scopes_ng::Scop hrtimer_start_range_ns    hrtimer_wakeup

  process 2812 is a thread of unity8-dash

  attaching strace to the thread we see:

  root@ubuntu-phablet:/proc# strace -p 2812 
  Process 2812 attached
  clock_gettime(CLOCK_MONOTONIC, {925, 47970238}) = 0
  epoll_wait(57, {}, 256, 115)            = 0
  clock_gettime(CLOCK_MONOTONIC, {925, 165670469}) = 0
  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
  fcntl64(50, F_GETFL)                    = 0x2 (flags O_RDWR)
  fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
  connect(50, {sa_family=AF_LOCAL, sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file or directory)
  close(50)                               = 0
  clock_gettime(CLOCK_MONOTONIC, {925, 174626930}) = 0
  epoll_wait(57, {}, 256, 39)             = 0
  clock_gettime(CLOCK_MONOTONIC, {925, 215561930}) = 0
  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
  fcntl64(50, F_GETFL)                    = 0x2 (flags O_RDWR)
  fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0
  connect(50, {sa_family=AF_LOCAL, sun_path="/run/user/32011/zmq/priv/clickscope"}, 110) = -1 ENOENT (No such file or directory)
  close(50)                               = 0
  clock_gettime(CLOCK_MONOTONIC, {925, 222932007}) = 0
  epoll_wait(57, {}, 256, 65)             = 0
  clock_gettime(CLOCK_MONOTONIC, {925, 290266777}) = 0
  socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 50
  fcntl64(50, F_GETFL)                    = 0x2 (flags O_RDWR)
  fcntl64(50, F_SETFL, O_RDWR|O_NONBLOCK) = 0

  ..ad infinitum...

  the epoll_wait() is sleeping a very short while before a connect to a
  clickscope named socket path is attempted over and over again. Is this
  rapid polling really necessary?   It's contributing to 0.50%-1.00% of
  the CPU load of the phone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1364464/+subscriptions