← Back to team overview

linaro-pm-wg team mailing list archive

[Blueprint hrtimer-range-and-clockevent] misc: make possible to use the range field of hrtimer into the clockevent driver


Blueprint changed by Dmitry Antipov:

Whiteboard changed:
  Hrtimer satisfies a wide range of requirements so optimizing it for powersaving can be an interesting task. Basically the clock event driver exposes the interface to schedule the actual next event interrupt. The time to schedule this interrupt is passed as a parameter by core timers interface after checking the other timers registered along with their ranges. This range field of Hrtimer is a important field in reducing the number of timers firing and thus less wakeus by merging the timers together.
  Some activity identified are,
  * Use sleep_range api's instead of normal sleep in drivers and test
  applications(check possibility). More such type of timers will help in
  * Use the range field of timers (Along with any synchronization needed)
  in the clock event driver itself before scheduling the next event
  * Benchmark and measure the C state idle wakeups and  no of process wakeups.
  A good way to test the benefit of adding a range parameter to the clock-event, is to check how this help to synchronize the wake-up/sleep sequence of the cores in the same cluster. The main benefit should be an increase on the cluster power down mode.
  Let start on each core a thread, which uses hrtimer with range, to simulate periodic activity. The use a range in clock event should help to synchronize the wakeup of cores and to the improve the time spent in cluster off mode
  Work items for 2012.01:
  [dmitry.antipov] implement core high-res timers feature to return time spent in usleep_range(): DONE
  [dmitry.antipov] adapt OMAP I2C driver to use this feature: DONE
  [dmitry.antipov] adapt SMSC95XX driver to use this feature: DONE
  [dmitry.antipov] convert MMC/SD host driver to usleep_range(): DONE
  Work items for 2012.02:
  [dmitry.antipov] Push mmc, omap_i2c and smsc95xx changes to mainline: INPROGRESS
  [dmitry.antipov] Find and classify the kernel wide timers other then hrtimer subsystem which uses clock event driver to register the h/w timer: TODO
  [dmitry.antipov] Implement a test case/benchmark to check whether high-res timers should be preferred over jiffies-backed timers in a different situations for a different kinds of workload: TODO
  [dmitry.antipov] To create a preliminary design or even sample implementation of putting the range field in clock event driver: TODO
  [dmitry.antipov] Get the above design reviewed before proceeding further: TODO
  Benchmark results obtained with oprofile on Panda board:
  There is a sample kernel module to create a lot of kernel threads, each
  of them do schedule_timeout_uninterruptible() or
  With default parameters (128 threads, 1 ms timeout) and jiffies-backed
- timeout, vmlinux profiling gives the following results:
+ timeout, profiling result are here:
- samples  %        samples  %        image name               app name                 symbol name
- 101123   96.9038  0              0  vmlinux                  vmlinux                  omap4_enter_idle
- 825       0.7906  13        0.0124  vmlinux                  vmlinux                  tick_nohz_idle_enter
- 726       0.6957  55        0.0526  vmlinux                  vmlinux                  __schedule
- 86        0.0824  7         0.0067  vmlinux                  vmlinux                  lock_acquire
- 77        0.0738  0              0  vmlinux                  vmlinux                  run_ksoftirqd
- 67        0.0642  5         0.0048  vmlinux                  vmlinux                  sub_preempt_count
- 63        0.0604  4         0.0038  vmlinux                  vmlinux                  tick_nohz_idle_exit
- 61        0.0585  0              0  vmlinux                  vmlinux                  __do_softirq
- 61        0.0585  3         0.0029  vmlinux                  vmlinux                  rcu_note_context_switch
- 56        0.0537  1        9.6e-04  vmlinux                  vmlinux                  add_preempt_count
+ https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc?action=AttachFile&do=get&target=jif-128-1.log
- For high-resolution timers timeout, vmlinux profiling gives the
- following:
+ For high-resolution timers-backed timeout, profiling results are here:
- samples  %        samples  %        image name               app name                 symbol name
- 5992     31.8013  0              0  vmlinux                  vmlinux                  omap4_enter_idle
- 3594     19.0744  3793      2.1795  vmlinux                  vmlinux                  __schedule
- 2917     15.4814  2804      1.6112  vmlinux                  vmlinux                  __hrtimer_start_range_ns
- 1224      6.4961  1235      0.7096  vmlinux                  vmlinux                  hrtimer_try_to_cancel
- 412       2.1866  483       0.2775  vmlinux                  vmlinux                  lock_acquire
- 328       1.7408  281       0.1615  vmlinux                  vmlinux                  schedule_hrtimeout_range_clock
- 298       1.5816  324       0.1862  vmlinux                  vmlinux                  finish_task_switch
- 232       1.2313  231       0.1327  vmlinux                  vmlinux                  rcu_note_context_switch
- 214       1.1358  265       0.1523  vmlinux                  vmlinux                  sub_preempt_count
- 190       1.0084  196       0.1126  vmlinux                  vmlinux                  thumbee_notifier
+ https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc?action=AttachFile&do=get&target=hrt-128-1.log

misc: make possible to use the range field of hrtimer into the clockevent driver