[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077537100F7@SHSMSX103.ccr.corp.intel.com>
Date: Wed, 21 Jun 2017 14:10:27 +0000
From: "Liang, Kan" <kan.liang@...el.com>
To: Don Zickus <dzickus@...hat.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"babu.moger@...cle.com" <babu.moger@...cle.com>,
"atomlin@...hat.com" <atomlin@...hat.com>,
"prarit@...hat.com" <prarit@...hat.com>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"eranian@...gle.com" <eranian@...gle.com>,
"acme@...hat.com" <acme@...hat.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] kernel/watchdog: fix spurious hard lockups
.
> On Wed, Jun 21, 2017 at 12:40:28PM +0000, Liang, Kan wrote:
> >
> > > >
> > > > The right fix for mainline can be found here.
> > > > perf/x86/intel: enable CPU ref_cycles for GP counter
> > > > perf/x86/intel,
> > > > watchdog: Switch NMI watchdog to ref cycles on x86
> > > > https://patchwork.kernel.org/patch/9779087/
> > > > https://patchwork.kernel.org/patch/9779089/
> > >
> > > Presumably the "right fix" will later be altered to revert this
> > > one-line workaround?
> >
> > The "right fix" itself will not touch the watchdog rate. I will modify
> > the changelog to notify the people who want to do the backport.
> >
> > As my understanding, it's not harmful even if we don't revert the
> > workaround. It can still detect the hardlockup, only takes a tiny bit
> > longer.
>
> It depends on you perspective of harmful. :-) There are folks that would like
> that sampling rate to be more accurate, so they can detect problems soon
> than later. You just took an input of 'watchdog_thresh' and blindly
> multiplied it by 3, which can confuse an end user who thought they setup a 5
> second threshold but instead it turned into a 15 second one. :-(
Now, it cannot get accurate threshold because of the Turbo.
We can only get an accurate one after applying the "right fix".
Right, we should revert the workaround once the "right fix" is applied.
Thanks,
Kan
Powered by blists - more mailing lists