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:0.671 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site