On Sat, 2014-12-13 at 09:11 +0100, Ingo Molnar wrote:
> * Mike Galbraith <umgwanakikb...@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?
I couldn't plug it into the production -ENOBOOT IO beasts from hell, but
did run it on my little desktop a bit.
> 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.
If watchdog gets credit for zillion disk detection time, it can end up
throttled for what is effectively forever.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
