| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Change-Id: I126075a330f305c85f8fe1b8c9d408f368be95d1
|
| |
|
|
| |
Change-Id: Ieb1067c5e276f872ed4c722b7d1fabecbdad87e7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is preferable that WALT window rollover occurs just
before a tick, since the tick is an opportune moment
to record a complete window's statistics, as well as report
those stats to the cpu frequency governor. When CONFIG_HZ
results in a TICK_NSEC that isn't a integral number, this
requirement may be violated. Account for this by reducing
the WALT window size to the nearest multiple of TICK_NSEC.
Commit d368c6faa19b ("sched: walt: fix window misalignment
when HZ=300") attempted to do this but WALT isn't using
MIN_SCHED_RAVG_WINDOW as the window size and the patch was
doing nothing.
Also, change the type of 'walt_disabled' to bool and warn
if an invalid window size causes WALT to be disabled.
Change-Id: Ie3dcfc21a3df4408254ca1165a355bbe391ed5c7
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Energy cost estimation has been a long lasting challenge for WALT
because WALT guides CPU frequency based on the CPU utilization of
previous window. Consequently it's not possible to know newly
waking-up task's energy cost until WALT's end of the current window.
The WALT already tracks 'Previous Runnable Sum' (prev_runnable_sum)
and 'Cumulative Runnable Average' (cr_avg). They are designed for
CPU frequency guidance and task placement but unfortunately both
are not suitable for the energy cost estimation.
It's because using prev_runnable_sum for energy cost calculation would
make us to account CPU and task's energy solely based on activity in the
previous window so for example, any task didn't have an activity in the
previous window will be accounted as a 'zero energy cost' task.
Energy estimation with cr_avg is what energy_diff() relies on at present.
However cr_avg can only represent instantaneous picture of energy cost
thus for example, if a CPU was fully occupied for an entire WALT window
and became idle just before window boundary, and if there is a wake-up,
energy_diff() accounts that CPU is a 'zero energy cost' CPU.
As a result, introduce a new accounting unit 'Cumulative Window Demand'.
The cumulative window demand tracks all the tasks' demands have seen in
current window which is neither instantaneous nor actual execution time.
Because task demand represents estimated scaled execution time when the
task runs a full window, accumulation of all the demands represents
predicted CPU load at the end of window.
Thus we can estimate CPU's frequency at the end of current WALT window
with the cumulative window demand.
The use of prev_runnable_sum for the CPU frequency guidance and cr_avg
for the task placement have not changed and these are going to be used
for both purpose while this patch aims to add an additional statistics.
Change-Id: I9908c77ead9973a26dea2b36c001c2baf944d4f5
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
There's no need for a separate hierarchy of notifiers, APIs
and variables in walt.c for the purpose of applying frequency
and IPC invariance. Let's just use capacity_curr_of and get
rid of a lot of the infrastructure relating to capacity,
load_scale_factor etc.
Change-Id: Ia220e2c896373fa535db05bff60f9aa33aefc978
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
|
| |
|
|
|
|
|
|
| |
The initial window start needs to be close to ktime ns = 0 to be
aligned with scheduler tick.
Change-Id: Ia91f74efce2f910106622a054a6fcd507e763ca5
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When running tasks's ravg.demand is changed update_history() adjusts
rq->cumulative_runnable_avg to reflect change of CPU load. Currently
this fixup is broken by accumulating task's new demand without
subtracting the task's old demand.
Fix the fixup logic to subtract the task's old demand.
Change-Id: I61beb32a4850879ccb39b733f5564251e465bfeb
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
| |
Due to rounding error hrtimer tick interval becomes 3333333 ns when HZ=300.
Consequently the tick time stamp nearest to the WALT's default window size
20ms will be also 19999998 (3333333 * 6).
Change-Id: I08f9bd2dbecccbb683e4490d06d8b0da703d3ab2
Suggested-by: Joel Fernandes <joelaf@google.com>
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
{min,max}_capacity are static variables that are only updated from
__update_min_max_capacity(), but not used anywhere else.
Remove them together with the function updating them. This has also
the nice side effect of fixing a LOCKDEP warning related to locking
all CPUs in update_min_max_capacity(), as reported by Ke Wang:
[ 2.853595] c0 =============================================
[ 2.859219] c0 [ INFO: possible recursive locking detected ]
[ 2.864852] c0 4.4.6+ #5 Tainted: G W
[ 2.869604] c0 ---------------------------------------------
[ 2.875230] c0 swapper/0/1 is trying to acquire lock:
[ 2.880248] (&rq->lock){-.-.-.}, at: [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 2.888815] c0
[ 2.888815] c0 but task is already holding lock:
[ 2.895132] (&rq->lock){-.-.-.}, at: [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 2.903700] c0
[ 2.903700] c0 other info that might help us debug this:
[ 2.910710] c0 Possible unsafe locking scenario:
[ 2.910710] c0
[ 2.917112] c0 CPU0
[ 2.919795] c0 ----
[ 2.922478] lock(&rq->lock);
[ 2.925507] lock(&rq->lock);
[ 2.928536] c0
[ 2.928536] c0 *** DEADLOCK ***
[ 2.928536] c0
[ 2.935200] c0 May be due to missing lock nesting notation
[ 2.935200] c0
[ 2.942471] c0 7 locks held by swapper/0/1:
[ 2.946623] #0: (&dev->mutex){......}, at: [<ffffff800850e118>] __driver_attach+0x64/0xb8
[ 2.954931] #1: (&dev->mutex){......}, at: [<ffffff800850e128>] __driver_attach+0x74/0xb8
[ 2.963239] #2: (cpu_hotplug.lock){++++++}, at: [<ffffff80080cb218>] get_online_cpus+0x48/0xa8
[ 2.971979] #3: (subsys mutex#6){+.+.+.}, at: [<ffffff800850bed4>] subsys_interface_register+0x44/0xc0
[ 2.981411] #4: (&policy->rwsem){+.+.+.}, at: [<ffffff8008720338>] cpufreq_online+0x330/0x76c
[ 2.990065] #5: ((cpufreq_policy_notifier_list).rwsem){.+.+..}, at: [<ffffff80080f3418>] blocking_notifier_call_chain+0x38/0xc4
[ 3.001661] #6: (&rq->lock){-.-.-.}, at: [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 3.010661] c0
[ 3.010661] c0 stack backtrace:
[ 3.015514] c0 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.4.6+ #5
[ 3.022864] c0 Hardware name: Spreadtrum SP9860g Board (DT)
[ 3.028402] c0 Call trace:
[ 3.031092] c0 [<ffffff800808b50c>] dump_backtrace+0x0/0x210
[ 3.036716] c0 [<ffffff800808b73c>] show_stack+0x20/0x28
[ 3.041994] c0 [<ffffff8008433310>] dump_stack+0xa8/0xe0
[ 3.047273] c0 [<ffffff80081349e0>] __lock_acquire+0x1e0c/0x2218
[ 3.053243] c0 [<ffffff80081353c0>] lock_acquire+0xe0/0x280
[ 3.058784] c0 [<ffffff8008abfdfc>] _raw_spin_lock+0x44/0x58
[ 3.064407] c0 [<ffffff80081241cc>] cpufreq_notifier_policy+0x2e8/0x37c
[ 3.070983] c0 [<ffffff80080f3458>] blocking_notifier_call_chain+0x78/0xc4
[ 3.077820] c0 [<ffffff8008720294>] cpufreq_online+0x28c/0x76c
[ 3.083618] c0 [<ffffff80087208a4>] cpufreq_add_dev+0x98/0xdc
[ 3.089331] c0 [<ffffff800850bf14>] subsys_interface_register+0x84/0xc0
[ 3.095907] c0 [<ffffff800871fa0c>] cpufreq_register_driver+0x168/0x28c
[ 3.102486] c0 [<ffffff80087272f8>] sprd_cpufreq_probe+0x134/0x19c
[ 3.108629] c0 [<ffffff8008510768>] platform_drv_probe+0x58/0xd0
[ 3.114599] c0 [<ffffff800850de2c>] driver_probe_device+0x1e8/0x470
[ 3.120830] c0 [<ffffff800850e168>] __driver_attach+0xb4/0xb8
[ 3.126541] c0 [<ffffff800850b750>] bus_for_each_dev+0x6c/0xac
[ 3.132339] c0 [<ffffff800850d6c0>] driver_attach+0x2c/0x34
[ 3.137877] c0 [<ffffff800850d234>] bus_add_driver+0x210/0x298
[ 3.143676] c0 [<ffffff800850f1f4>] driver_register+0x7c/0x114
[ 3.149476] c0 [<ffffff8008510654>] __platform_driver_register+0x60/0x6c
[ 3.156139] c0 [<ffffff8008f49f40>] sprd_cpufreq_platdrv_init+0x18/0x20
[ 3.162714] c0 [<ffffff8008082a64>] do_one_initcall+0xd0/0x1d8
[ 3.168514] c0 [<ffffff8008f0bc58>] kernel_init_freeable+0x1fc/0x29c
[ 3.174834] c0 [<ffffff8008ab554c>] kernel_init+0x20/0x12c
[ 3.180281] c0 [<ffffff8008086290>] ret_from_fork+0x10/0x40
Reported-by: Ke Wang <ke.wang@spreadtrum.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
On at least one platform, occasionally the timer providing the wallclock
was able to be reset/go backwards for at least some time after wakeup.
Accept that this might happen and warn the first time, but otherwise just
carry on.
Change-Id: Id3164477ba79049561af7f0889cbeebc199ead4e
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
|
| |
|
|
|
|
|
|
|
| |
Include clocksource/arm_arch_timer.h to fix implicit function
declaration of ‘arch_timer_read_counter’ build error for ARCH=arm.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
[jstultz: Cherry-picked from common/android-3.18]
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Bug: 29000863
Signed-off-by: albert.zl_huang <albert.zl_huang@htc.com>
Change-Id: I2b5a28b0a9edb31bdaa1ca2310397dd2f36f6c23
Updated to use arch_timer_read_counter() as arch_counter_get_cntvct
doesn't exist in this kernel.
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
|
| |
|
|
|
|
|
| |
Schedules on a core whose irq count is less than a threshold.
Improves I/O performance of EAS.
Change-Id: I08ff7dd0d22502a0106fc636b1af2e6fe9e758b5
|
|
|
use a window based view of time in order to track task
demand and CPU utilization in the scheduler.
Window Assisted Load Tracking (WALT) implementation credits:
Srivatsa Vaddagiri, Steve Muckle, Syed Rameez Mustafa, Joonwoo Park,
Pavan Kumar Kondeti, Olav Haugan
2016-03-06: Integration with EAS/refactoring by Vikram Mulukutla
and Todd Kjos
Change-Id: I21408236836625d4e7d7de1843d20ed5ff36c708
Includes fixes for issues:
eas/walt: Use walt_ktime_clock() instead of ktime_get_ns() to avoid a
race resulting in watchdog resets
BUG: 29353986
Change-Id: Ic1820e22a136f7c7ebd6f42e15f14d470f6bbbdb
Handle walt accounting anomoly during resume
During resume, there is a corner case where on wakeup, a task's
prev_runnable_sum can go negative. This is a workaround that
fixes the condition and warns (instead of crashing).
BUG: 29464099
Change-Id: I173e7874324b31a3584435530281708145773508
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Srinath Sridharan <srinathsr@google.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
[jstultz: fwdported to 4.4]
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
