lkml.org 
[lkml]   [2014]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: frequent lockups in 3.18rc4
From
Date
On Sat, 2014-12-13 at 09:11 +0100, Ingo Molnar wrote: 
> * 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?

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



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