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. Thanks. 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 fine. 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 experiments? Thanks in advance, Suresh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
