cpufreq: interactive: Handle notification even if timer fires first

Scheduler provides different load number based on whether a
notification is pending. Under normal situation, it won't provide a
load that exceeds 100% busy time of current frequency. For migration,
the busy time can be huge if a heavy task just moved to the CPU.

This creates a race condition due to how governor handles
notification:
1) Scheduler sends notification for a big task
2) Governor timer runs, and gets a huge load, but fails to skip
hispeed_freq logic and all delays because it's not a notification
3) After receiving sched_get_cpus_busy(), scheduler thinks governor has
finished handling the notification and changes to provide normal load
that is capped to 100% of the CPU at current frequency.
4) Governor now starts handling notification, but gets a small load
that doesn't reflect real demand of the heavy task.

The migration notification is thus effectively lost. Fixing this by
making notification pending a per-cpu flag. If timer gets ahead of
notification handling, it will be run as if it's a notification.

Change-Id: Ie3d68edf85b822232a646c2694bec6928a2d7cd1
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>

0 files changed, 0 insertions, 0 deletions