From: Chen Yucong <slaoub@gmail.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU
Date: Fri, 23 May 2014 19:57:06 +0800 [thread overview]
Message-ID: <1400846226.25914.16.camel@debian> (raw)
In-Reply-To: <20140523091041.GA21332@pd.tnic>
On Fri, 2014-05-23 at 11:10 +0200, Borislav Petkov wrote:
> On Fri, May 23, 2014 at 09:32:19AM +0800, Chen Yucong wrote:
> > ...if we reach a timeout, there is very little
> > chance for recovering. Thought. the probability for this situation to
> > happen is very slight, it's not impossible. Indeed, it's hard to know
> > the precise causes for timeout.
OK, we can exclude the timeout.
Why can not we distribute the clear operations of mces_seen to Per-CPU?
Why must monarch need to help all other CPUs to clean mces_seen? What's
the advantage for this?
Why do we have to discard the property of Per-CPU variable?
Why can not we reduce the processing time of monarch CPU?
...
>
> Ok, enough talking, let's close that hole and get on with our lives:
You can safely ignore all messages about this talking.
>
> There is very little and maybe practically nothing we can do to recover
> from a system where at least one core has reached a timeout during the
> whole monarch cores gathering. So panic when that happens.
>
Why do you prefer to use "very little" and "maybe practically"?
Do you still not sure about that?
> if ((s64)*t < SPINUNIT) {
> - /* CHECKME: Make panic default for 1 too? */
> - if (mca_cfg.tolerant < 1)
> + if (mca_cfg.tolerant <= 1)
If (mca_cfg.tolerant == 2 || mce_cfg.tolerant == 3), what can you do for
it?
> mce_panic("Timeout synchronizing machine check over CPUs",
> NULL, NULL);
> cpu_missing = 1;
> --
> 1.9.0
>
next prev parent reply other threads:[~2014-05-23 11:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 2:11 [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU Chen Yucong
2014-05-20 17:33 ` Borislav Petkov
2014-05-21 0:48 ` Chen Yucong
2014-05-21 1:33 ` Chen Yucong
2014-05-21 1:40 ` Hidetoshi Seto
2014-05-21 2:03 ` Chen Yucong
2014-05-21 2:43 ` Hidetoshi Seto
2014-05-21 3:19 ` Chen Yucong
2014-05-21 3:36 ` Hidetoshi Seto
2014-05-21 21:09 ` Luck, Tony
2014-05-23 1:32 ` Chen Yucong
2014-05-23 9:10 ` Borislav Petkov
2014-05-23 11:57 ` Chen Yucong [this message]
2014-05-23 22:40 ` Tony Luck
2014-05-23 21:50 ` Tony Luck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1400846226.25914.16.camel@debian \
--to=slaoub@gmail.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tony.luck@intel.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox