Re: Serious power saving with dbus-scripts and pkill -STOP
Quote:
Originally Posted by vi_
(Post 1031376)
tl;dr I suspect dbus-scripts cause more system load checking to see if it needs to run a script in response to an event than the processes you are trying to kill.
|
Before even posting this thread I ran PowerTop, and my CPU wakeups were reduced over leaving MSCIM running. Here's an example powertop output:
Code:
Powertop 1.13.3
Sleeping for 11 seconds before sampling
Collecting data for 30 seconds
Sample interval was 00m 30s 28717us
C# | Ratio | Avg/dura | Frequency | Ratio
--------+--------+----------+-----------+--------+
C0 | 1.5% | | 1150 MHz | nan% |
C1 | 0.0% | 0.1ms |
C2 | 0.4% | 1.0ms |
C3 | 0.6% | 93.1ms |
C4 | 97.5% | 1330.3ms |
IRQ# | Activity | Type | Name
--------+------------+----------------+---------------------------
56 | 2777 | INTC | i2c_omap
37 | 66 | INTC | gp
57 | 61 | INTC | i2c_omap
11 | 55 | INTC | prcm
PID# | Activity | Name | Function Entry (Expire)
--------+------------+----------------+---------------------------
750 | 33 | bme_RX-51 | sys_timer_settime (posix_timer_fn)
38 | 23D| awk | cpufreq_governor_dbs (delayed_work_timer_fn)
0 | 18 | <kernel core> | tick_nohz_restart_sched_tick (tick_sched_timer)
750 | 18 | bme_RX-51 | schedule_timeout (process_timeout)
1 | 3 | <kernel core> | queue_delayed_work (delayed_work_timer_fn)
750 | 2 | bme_RX-51 | do_nanosleep (hrtimer_wakeup)
714 | 2 | dsme | do_nanosleep (hrtimer_wakeup)
714 | 2 | dsme | __enqueue_rt_entity (sched_rt_period_timer)
1086 | 2D|<kernel module> | queue_delayed_work (delayed_work_timer_fn)
0 | 1 | <kernel core> | hrtimer_start (tick_sched_timer)
1338 | 1 | hildon-home | schedule_hrtimeout_range (hrtimer_wakeup)
1733 | 1 | powertop | do_nanosleep (hrtimer_wakeup)
Power domain activity breakdown
Domain | % of time spent in states
--------+---------+---------+---------+---------+----------
usbhost |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
sgx |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
per |OFF: 98%|RET: 0%|INA: 0%| ON: 1%| now:(ON)
dss |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
cam |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
core |OFF: 97%|RET: 0%|INA: 0%| ON: 1%| now:(ON)
neon |OFF: 97%|RET: 0%|INA: 0%| ON: 1%| now:(ON)
mpu |OFF: 97%|RET: 0%|INA: 0%| ON: 1%| now:(ON)
iva2 |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
iva2 |OFF: 100%|RET: 0%|INA: 0%| ON: 0%| now:(OFF)
Clock activity breakdown at end of period
Domain | Active clocks
--------+---------------+---------------+------------------
core | SDRC | HSOTGUSB_IDLE | OMAPCTRL
| MAILBOXES |
wkup | GPT1 | 32KSYNC | GPIO1
|
ckgen | CORE | PERI | 96M
| 48M | 12M | 54M
| EMU_CORE |
per | GPIO2 | GPIO3 | GPIO4
| GPIO5 | GPIO6 |
Total wakeups 3065, 102.2/s | IRQ 2959, 98.6/s | Timers 106, 3.5/s
HW wakeups 55, 1.8/s | Real gp_timers expired 66, 2.2/s
Now, obviously the overhead of dbus-scripts will exceed the resource usage of some, maybe most, processes/applications. That does not mean that there are no use cases for this idea. |
