lkml.org 
[lkml]   [2014]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: frequent lockups in 3.18rc4

    * Mike Galbraith <umgwanakikbuti@gmail.com> wrote:

    > On Tue, 2014-12-02 at 08:33 -0800, Linus Torvalds wrote:
    >
    > > Looking again at that patch (the commit message still doesn't strike
    > > me as wonderfully explanatory :^) makes me worry, though.
    > >
    > > Is that
    > >
    > > if (rq->skip_clock_update-- > 0)
    > > return;
    > >
    > > really right? If skip_clock_update was zero (normal), it now gets set
    > > to -1, which has its own specific meaning (see "force clock update"
    > > comment in kernel/sched/rt.c). Is that intentional? That seems insane.
    >
    > Yeah, it was intentional. Least lines.
    >
    > > Or should it be
    > >
    > > if (rq->skip_clock_update > 0) {
    > > rq->skip_clock_update = 0;
    > > return;
    > > }
    > >
    > > or what? Maybe there was a reason the patch never got applied even to -tip.
    >
    > Peterz was looking at corner case proofing the thing. Saving those
    > cycles has been entirely too annoying.
    >
    > https://lkml.org/lkml/2014/4/8/295

    Hm, so that discussion died with:

    https://lkml.org/lkml/2014/4/8/343

    Did you ever get around to trying Peter's patch?

    But ... I've yet to see rq_clock problems cause actual lockups.
    That's the main problem we have with its (un)robustness and why
    Peter created that rq_clock debug facility: bugs there cause
    latencies but no easily actionable symptoms, which are much
    harder to debug.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2014-12-13 09:41    [W:4.196 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site