lkml.org 
[lkml]   [2008]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: TSC not updating after resume: Bug or Feature?
    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.

    > The original description sounds worrisome to me, it looks like we've overlooked
    > something at least.

    Care to explain ?

    > > > His patch fixes the backward motion filter and I'm at an utter
    > > > loss why that would break suspend.
    > >
    > > yes, i'd love to have this commit reinstated:
    > >
    > > 5b7dba4: sched_clock: prevent scd->clock from moving backwards
    > >
    > > and the bug triggered by hibernation fixed instead.

    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



    \
     
     \ /
      Last update: 2008-12-21 17:31    [W:0.023 / U:59.788 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site