On Fri, Sep 14, 2018 at 2:41 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Fri, 14 Sep 2018, Rafael J. Wysocki wrote: > > On Fri, Sep 14, 2018 at 11:53 AM Mika Penttilä > > > > >> But doesn't injecting sleep time here make monotonic clock too large > > > >> by the amount of sleeptime? tick_freeze() / tick_unfreeze() already > > > >> injects the sleeptime (otherwise delta would be 0). > > > > > > > > > > > No, it doesn't. > > > > > > > > The delta here is the extra time taken by the loop which hasn't been counted > > > > as sleep time yet. > > > > > > > I said incorrectly monotonic clock, but > > > timekeeping_inject_sleeptime64() forwards the wall time, by the amount > > > of delta. Why wouldn't some other cpu update xtime when one cpu is in > > > the loop? And if all cpus enter s2idle, tick_unfreeze() injects > > > sleeptime. My point is that this extra injection makes wall time wrong, > > > no? > > > > OK, you're right. I got that the other way around. > > > > So, the patch is withdrawn. [Sorry for the delay, personal life intervened.] > I just tried to wrap my brain around that whole thing and utterly > failed, so I can't give any recommendations right now. Thanks for looking into this! > Rafael, could you please enable some lightweight instrumentation which lets > me see the longer sequence of events which are leading to this or tell me > what I need to do to reproduce that myself? I will, when I find out more. The reported issues may just go away after fixing some other bugs. Cheers, Rafael
