On Mon, 2010-06-14 at 00:46 -0700, Suresh Rajashekara wrote: > 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. Ah, the sleep time is probably too coarse (seconds). We probably need to increase the granularity from read_persistent_clock() and see if that helps (although most persistent clocks aren't very fine grained). > Also another side effect of this change was that the system time was > no longer in sync with the wall time. ? This doesn't make much sense to me, as you shouldn't be manipulating xtime differently. Just to be clear, you mean the value from "date" doesn't match your watch after resume? > 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? Well, the difficultly here is what folks actually mean by suspend. On some hardware it means everything is powered off, and so on resume we have to re-init hardware values. It seems in your case that the hardware isn't completely powered off, since the clocksource you're using seemed to continue counting while the system was suspended. So in this case you might be ok. Your suspend seems closer to an deep idle state on x86. So suspending timekeeping might not be necessary. However, you're right that there may be lurking issues: 1) The suspend time would have to be limited to the clocksource's max_idle_ns value, since after that amount of cycles have past, we might overflow the accumulation function, or the clocksource may have wrapped. 2) If the hardware does reset the clocksource at some point during the suspend, you'll have odd time issues. 3) You could run into some difficulty keeping close sync with an NTP server, as the long delays between accumulation will probably cause an oscillating over-shoot and over-correction. I suspect these different definitions of "suspend" on all of the different hardware types out there is going to be a growing problem in the near term. Especially as deep idle states start to power off more hardware and becomes closer to suspend in behavior. thanks -john -- 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
