Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-22 Thread Stephen Boyd
On 07/18/14 17:14, John Stultz wrote: > On 07/18/2014 04:24 PM, Stephen Boyd wrote: >> On 07/18/14 15:42, John Stultz wrote: >>> If its a regression (and needs -stable backports) it needs to go in via >>> tip/timers/urgent, and not via the regular merge window. >>> >>> Whats the additional risk

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-22 Thread Stephen Boyd
On 07/18/14 17:14, John Stultz wrote: On 07/18/2014 04:24 PM, Stephen Boyd wrote: On 07/18/14 15:42, John Stultz wrote: If its a regression (and needs -stable backports) it needs to go in via tip/timers/urgent, and not via the regular merge window. Whats the additional risk -stable wise for

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread John Stultz
On 07/18/2014 04:24 PM, Stephen Boyd wrote: > On 07/18/14 15:42, John Stultz wrote: >> If its a regression (and needs -stable backports) it needs to go in via >> tip/timers/urgent, and not via the regular merge window. >> >> Whats the additional risk -stable wise for canceling the timer during >>

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread Stephen Boyd
On 07/18/14 15:42, John Stultz wrote: > If its a regression (and needs -stable backports) it needs to go in via > tip/timers/urgent, and not via the regular merge window. > > Whats the additional risk -stable wise for canceling the timer during > suspend and starting it back up during resume? >

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread John Stultz
On 07/18/2014 03:38 PM, Stephen Boyd wrote: > On 07/18/14 15:25, John Stultz wrote: >> On 07/18/2014 03:09 PM, Stephen Boyd wrote: >>> During suspend we call sched_clock_poll() to update the epoch and >>> accumulated time and reprogram the sched_clock_timer to fire >>> before the next wrap-around

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread Stephen Boyd
On 07/18/14 15:25, John Stultz wrote: > On 07/18/2014 03:09 PM, Stephen Boyd wrote: >> During suspend we call sched_clock_poll() to update the epoch and >> accumulated time and reprogram the sched_clock_timer to fire >> before the next wrap-around time. Unfortunately, >> sched_clock_poll() doesn't

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread John Stultz
On 07/18/2014 03:09 PM, Stephen Boyd wrote: > During suspend we call sched_clock_poll() to update the epoch and > accumulated time and reprogram the sched_clock_timer to fire > before the next wrap-around time. Unfortunately, > sched_clock_poll() doesn't restart the timer, instead it relies > on

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread John Stultz
On 07/18/2014 03:09 PM, Stephen Boyd wrote: During suspend we call sched_clock_poll() to update the epoch and accumulated time and reprogram the sched_clock_timer to fire before the next wrap-around time. Unfortunately, sched_clock_poll() doesn't restart the timer, instead it relies on the

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread Stephen Boyd
On 07/18/14 15:25, John Stultz wrote: On 07/18/2014 03:09 PM, Stephen Boyd wrote: During suspend we call sched_clock_poll() to update the epoch and accumulated time and reprogram the sched_clock_timer to fire before the next wrap-around time. Unfortunately, sched_clock_poll() doesn't restart

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread John Stultz
On 07/18/2014 03:38 PM, Stephen Boyd wrote: On 07/18/14 15:25, John Stultz wrote: On 07/18/2014 03:09 PM, Stephen Boyd wrote: During suspend we call sched_clock_poll() to update the epoch and accumulated time and reprogram the sched_clock_timer to fire before the next wrap-around time.

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread Stephen Boyd
On 07/18/14 15:42, John Stultz wrote: If its a regression (and needs -stable backports) it needs to go in via tip/timers/urgent, and not via the regular merge window. Whats the additional risk -stable wise for canceling the timer during suspend and starting it back up during resume? I'd say

Re: [PATCH] sched_clock: Avoid corrupting hrtimer tree during suspend

2014-07-18 Thread John Stultz
On 07/18/2014 04:24 PM, Stephen Boyd wrote: On 07/18/14 15:42, John Stultz wrote: If its a regression (and needs -stable backports) it needs to go in via tip/timers/urgent, and not via the regular merge window. Whats the additional risk -stable wise for canceling the timer during suspend and