[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110414153318.GA13891@sgi.com>
Date: Thu, 14 Apr 2011 10:33:18 -0500
From: Russ Anderson <rja@....com>
To: Borislav Petkov <bp@...64.org>
Cc: Prarit Bhargava <prarit@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Luck, Tony" <tony.luck@...el.com>,
"dzickus@...hat.com" <dzickus@...hat.com>,
"mstowe@...hat.com" <mstowe@...hat.com>,
"dnelson@...hat.com" <dnelson@...hat.com>, rja@...ricas.sgi.com
Subject: Re: [PATCH -v3] x86, MCE: Drop the default decoding notifier
On Thu, Apr 14, 2011 at 05:16:21PM +0200, Borislav Petkov wrote:
> On Thu, Apr 14, 2011 at 11:04:43AM -0400, Prarit Bhargava wrote:
> > On 04/14/2011 11:00 AM, Borislav Petkov wrote:
> > > On Wed, Apr 13, 2011 at 01:37:05PM -0400, Borislav Petkov wrote:
> > >
> > >> In the worst case, we will report 32 CEs before panicking. For that case
> > >> we either do printk_once as Tony suggested or we ratelimit it. I'll
> > >> update the patch.
> > >>
> > > Ok, how about the following, I ratelimit the printk to the default of 10
> > > messages per 5 seconds. I've also got the hardware MCE injection patches
> > > ready and will do some testing with them.
> > >
> >
> > See my previous email ;) I think just putting in a printk_once after
> > the CE call to print_mce() in mce_panic() might be better? At least
> > that way we get the --ascii message for *EVERY* UC which IMO would be
> > nice...
>
> Are you sure? printk_once() is, as its name says, a one-time thing and
> it is implemented that way - a static bool counter which is once set and
> that's it. I.e., the "--ascii" message will be printed only once for the
> system's lifetime.
>
> The ratelimit-ed thing dumps it a strict number of times. In the end,
> I don't have a strong opinion on how many times we issue it - I'm fine
> with it either way.
>
> Maybe some other opinions. Tony?
In general I think you and Prarit are headed in the right direction.
As for when to throttle messages, differing people will have
different opinions as to the right number. For example, some
sites may want the threshold low because once they see a CE they
will schedule to replace the DIMM. Manufacturing sometimes
wants to see all the CEs to know how good/bad the DIMM is.
My suggestion is to pick a default value and have a /sys (or
other) way of changing the value. That way if someone has
a need to change the value they can. In real life someone
will have a legitimate need to change the value.
Is the thresholding on a per DIMM, per Socket, or per system
basis? SGI tends to have large systems with lots of DIMMs.
Per DIMM or per Socket thresholds tend to scale better.
Thanks,
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@....com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists