Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: TSC not updating after resume: Bug or Feature? | Date | Tue, 23 Dec 2008 01:47:31 +0100 |
| |
On Sunday, 21 of December 2008, Thomas Gleixner wrote: > On Thu, 18 Dec 2008, Rafael J. Wysocki wrote: > > > On Thursday, 18 of December 2008, Ingo Molnar wrote: > > > > > > * Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > > Rafael, would something like this explain why we had to revert Shaggy's > > > > patch? > > > > Well, I have yet to understand what the suspend-resume of the timekeeping code > > actually does. > > Thats rather simple: > > suspend() saves the current time of the persistent clock (if > available), forwards the timekeeping variables so they can be reused > on resume, disables timekeeping activities and shuts down the clock > events layer. > > resume() estimates the suspend time via persistent clock (if > available) and update xtime with the sleep length. After that it > reactivates timekeeping and resumes clock events and high resolution > timers. > > So the sole purpose is: > - dis/enable timekeeping and clock event devices. > - keep track of the suspend time (if a persistent clock is available) > > We reactivate clock event devices and hrtimers from timekeeping_resume > because clock events depend on functional timekeeping.
Thanks for the explanation. In fact, the reactivation of clock event devices and hrtimers is the part I'm not familiar with.
> > The original description sounds worrisome to me, it looks like we've overlooked > > something at least. > > Care to explain ?
Well, the fact that in the resume code path the clocksource is only updated as a result of executing pci_set_power_state() is worrisome. I would be more reliable to update it directly at one point.
Thanks, Rafael
| |