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.
Care to explain ?
Hmm. Depending on the hibernation sleep time we can end up with a
pretty long delta between the pre suspend and the post resume call to
__update_sched_clock().
I have the feeling that sched_clock looks into stale values after
resume and the first call to __update_sched_clock() trips over the
stale scd->clock value. Shaggy's patch brings scd->clock into the mix
and that might cause the whole machinery to blow up on resume.
Also we need to investigate whether sched_clock is referencing gtod
values _before_ timekeeping is resume.
Thanks,
tglx
--
