diff options
author | Srivatsa Vaddagiri <vatsa@codeaurora.org> | 2013-12-20 18:56:07 -0800 |
---|---|---|
committer | David Keitel <dkeitel@codeaurora.org> | 2016-03-23 19:58:42 -0700 |
commit | df74672faf8421bf0f133d7fe7422a7cd2f757a1 (patch) | |
tree | 46bbbcd99e95a04527c64c02f8444e7a44c5ecd8 /drivers/pps/sysfs.c | |
parent | e80ff9a87c1a797ed6f8fe2ef2f43f3f858170ad (diff) |
cpufreq: cpu-boost: Resolve deadlock when waking up sync thread
CPU boost driver receives notification from scheduler when threads
migrate towards a cpu and in turn wakes up a sync thread associated
with that cpu to handle any required frequency transitions. The wakeup
call however can lead to a deadlock inside scheduler under some
circumstance. The deadlock is seen when sync thread is the only thread
running on a cpu and goes to sleep (say by calling wait_event() ->
schedule()). Midway through this sleep (schedule()) call, while cpu is
still running in context of sync thread, scheduler attempts a load
balance (realizing that cpu is about to become idle) which can result
in tasks being migrated towards the cpu going idle. This will cause
migration notification to be issued and in turn a wakeup on sync
thread. The wakeup call however gets stuck in below while() loop
inside scheduler:
try_to_wake_up(struct task_struct *p, ...)
{
/*
* If the owning (remote) cpu is still in the middle of
* schedule() with this task as prev, wait until its done
* referencing the task.
*/
while (p->on_cpu)
cpu_relax();
}
A possible fix could be to teach try_to_wake_up() about this
special case. Another fix, implemented in this patch and that helps
minimize scheduler changes, is to have cpu boost driver not issue a
wakeup under this special circumstance, which was found to occur very
infrequently.
Change-Id: I92bc68a22d51595a208673fe2a1eedfa97004f9e
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Diffstat (limited to 'drivers/pps/sysfs.c')
0 files changed, 0 insertions, 0 deletions