Re: Timekeeping issue on aggressive suspend/resume

From: Suresh Rajashekara
Date: Mon Jun 14 2010 - 03:47:16 EST

On Thu, Jun 10, 2010 at 12:52 PM, john stultz <johnstul@xxxxxxxxxx> wrote:
> I think Thomas was suggesting that you consider creating a option for
> where CLOCK_MONOTONIC included total_sleep_time.
> In that case the *hack* (and this is a hack, we'll need some more
> thoughtful discussion before anything like it could make it upstream)
> would be in timekeeping_resume() to comment out the lines that update
> wall_to_monotonic and total_sleep_time.
> It would be interesting to hear if that hack works for you, and we can
> try to come up with a better way to think about how to accommodate both
> views of how to account time over suspend.


I tried this fix. It seemed to help, however the accuracy of sleep
time for the process was not quite right. A process thread which was
supposed to wake up every (X) seconds, seemed to wake up every (X -
delta X) seconds.

Also another side effect of this change was that the system time was
no longer in sync with the wall time.

These problems were more pronounced when the suspend/wakeup cycle time
was brought down to 0.5 seconds from 4 seconds. The periodicity of
most of the process threads were disturbed.

I decided to NOT suspend/resume the timekeeping subsystem in the
kernel and try. It seemed to work. Every application seems to work

Now my question is; Is it safe to disable suspend/resume of the
timekeeping subsystem? Will it have an effect (on
functionality/performance) which may not surface in my short

Thanks in advance,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at