sched/walt: Fix a potential accounting issue during window size change

There is a potential accounting issue during window size change, if
the roll over is delayed such that the current task's mark start went
past the new window start with the updated window size.

For example, system is running with window size = 20 msec. So it would be
like

20 | 40 | 60 | 80 | 100 | 120

At t= 98, the window size is changed to 8 msec. We expect this to be
handled at the next window roll over i.e t = 100

For some reason 98 < t < 109, interrupts are blocked on a CPU on which
roll over is supposed to happen.

Now at t = 109, the window roll over happen in the IRQ work. First
we roll over the window such that

wallclock (wc) = 109,
mark_start (ms) = 109,
window_start (ws) = 100.

New window size is set to 8 msec. At this point, we did not realize that
the ms/wc is went past the next window i.e 100 + 8 = 108 msec.

At t = 110, a task wakes up. We first call update_task_ravg() on the
current, for which ms = 109. We detect the window roll over but fail
to roll over the CPU busy time counters (prs/crs) since ms > ws.
see update_cpu_busy_time() for new_window detection. Now the utra()
is called for the waking task and its ms < ws and we roll over window for
it. if it migrates to another CPU, we try to subtract this task prs from
the CPU's prs which is not updated. This results in accounting issues.

This problem can be fixed easily by detecting the delayed window roll over
and deferring the window size update to next window roll over. Since this
is a very rare event, we don't miss anything. Also this is more optimized
compared to any changes in update_task_ravg() which is called many times
compared to a window roll over with a window size update pending.

Change-Id: Ia6e1750e632bf7594f0f83656986ad4393bfbe5a
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>