unity-api-bugs team mailing list archive

[Colin King <1221751@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

I've instrumented indicator-datetime on a Samsung Galaxy Nexus phone on
the ubuntu-touch images and it is quite a busy programme.

I ran health-check (http://kernel.ubuntu.com/~cking/health-check)
against it for 10 minutes and observed some interesting issues:

1. Quite a lot of active poll calls:

Top polling system calls:
  PID  Process              Syscall             Rate/Sec   Infinite   Zero     Minimum    Maximum    Average
                                                           Timeouts Timeouts   Timeout    Timeout    Timeout
  1379 indicator-datetime-s poll                    4.5533      492     2240   0.0 sec    0.0 sec    0.0 sec 
  1380 indicator-datetime-s poll                    0.7950       72       72   0.0 sec   25.0 sec   17.5 sec 
  1352 indicator-datetime-s poll                    0.5167       72       11   0.0 sec  180.0 sec   85.7 sec 
  1375 indicator-datetime-s poll                    0.1450       14       12   0.0 sec   25.0 sec   17.5 sec 
 Total                                              6.0100      650     2335

I guess these are from glib's  g_main_context_poll(), but it does seem
quite busy.

2. I think the polling blocking/waking is causing quite a lot of context
switches:

Context Switches:
  PID  Process                Voluntary   Involuntary     Total
                             Ctxt Sw/Sec  Ctxt Sw/Sec  Ctxt Sw/Sec
  1379 indicator-datetime-s        29.38         1.27        30.66 (moderate)
  1380 indicator-datetime-s        11.01         0.05        11.06 (moderate)
  1352 indicator-datetime-s         8.52         0.22         8.73 (low)
  1375 indicator-datetime-s         1.87         0.00         1.88 (low)
  1378 indicator-datetime-s         0.00         0.00         0.00 (idle)
 Total                             50.79         1.54        52.33
 
50 or so a second perhaps could be considered a little excessive for an indicator

3. Open/Closing of /etc/localtime without actually seemingly reading
data. Over a 10 minute interval we observe:

File I/O operations:
  PID  Process               Count  Op  Filename
  1352 indicator-datetime-s    119    C /etc/localtime
  1352 indicator-datetime-s    119    O /etc/localtime
  1352 indicator-datetime-s      2   OC /etc/localtime
 Total                         240

So that makes an access to /etc/localtime every 5 seconds for no real
purpose.  This seems like unnecessary activity - why do we need to keep
peeking at this file every 5 seconds, it doesn't change that often ;-)

For reference, I will add the full health-check report to the bug
report.

** Affects: indicator-datetime
     Importance: Undecided
         Status: New

** Affects: ubuntu-power-consumption
     Importance: Undecided
         Status: New

** Attachment added: "health-check-indicator-datetime-report.log"
   https://bugs.launchpad.net/bugs/1221751/+attachment/3805721/+files/health-check-indicator-datetime-report.log

** Also affects: ubuntu-power-consumption
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Unity API
bugs, which is subscribed to Indicator Date and Time.
https://bugs.launchpad.net/bugs/1221751

Title:
  on an idle system indicator-datetime is actually quite busy

Status in The Date and Time Indicator:
  New
Status in The Ubuntu Power Consumption Project:
  New

Bug description:
  I've instrumented indicator-datetime on a Samsung Galaxy Nexus phone
  on the ubuntu-touch images and it is quite a busy programme.

  I ran health-check (http://kernel.ubuntu.com/~cking/health-check)
  against it for 10 minutes and observed some interesting issues:

  1. Quite a lot of active poll calls:

  Top polling system calls:
    PID  Process              Syscall             Rate/Sec   Infinite   Zero     Minimum    Maximum    Average
                                                             Timeouts Timeouts   Timeout    Timeout    Timeout
    1379 indicator-datetime-s poll                    4.5533      492     2240   0.0 sec    0.0 sec    0.0 sec 
    1380 indicator-datetime-s poll                    0.7950       72       72   0.0 sec   25.0 sec   17.5 sec 
    1352 indicator-datetime-s poll                    0.5167       72       11   0.0 sec  180.0 sec   85.7 sec 
    1375 indicator-datetime-s poll                    0.1450       14       12   0.0 sec   25.0 sec   17.5 sec 
   Total                                              6.0100      650     2335

  I guess these are from glib's  g_main_context_poll(), but it does seem
  quite busy.

  2. I think the polling blocking/waking is causing quite a lot of
  context switches:

  Context Switches:
    PID  Process                Voluntary   Involuntary     Total
                               Ctxt Sw/Sec  Ctxt Sw/Sec  Ctxt Sw/Sec
    1379 indicator-datetime-s        29.38         1.27        30.66 (moderate)
    1380 indicator-datetime-s        11.01         0.05        11.06 (moderate)
    1352 indicator-datetime-s         8.52         0.22         8.73 (low)
    1375 indicator-datetime-s         1.87         0.00         1.88 (low)
    1378 indicator-datetime-s         0.00         0.00         0.00 (idle)
   Total                             50.79         1.54        52.33
   
  50 or so a second perhaps could be considered a little excessive for an indicator

  3. Open/Closing of /etc/localtime without actually seemingly reading
  data. Over a 10 minute interval we observe:

  File I/O operations:
    PID  Process               Count  Op  Filename
    1352 indicator-datetime-s    119    C /etc/localtime
    1352 indicator-datetime-s    119    O /etc/localtime
    1352 indicator-datetime-s      2   OC /etc/localtime
   Total                         240

  So that makes an access to /etc/localtime every 5 seconds for no real
  purpose.  This seems like unnecessary activity - why do we need to
  keep peeking at this file every 5 seconds, it doesn't change that
  often ;-)

  For reference, I will add the full health-check report to the bug
  report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/indicator-datetime/+bug/1221751/+subscriptions