From: Thomas Gleixner <tglx@linutronix.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Chen Gong <gong.chen@linux.intel.com>,
"bp@amd64.org" <bp@amd64.org>, "x86@kernel.org" <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: RE: [PATCH] x86: auto poll/interrupt mode switch for CMC to stop CMC storm
Date: Thu, 24 May 2012 20:18:07 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.02.1205242013490.3231@ionos> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F192F37C0@ORSMSX104.amr.corp.intel.com>
On Thu, 24 May 2012, Luck, Tony wrote:
> > So can you please explain how this is better than having this strict
> > per cpu and avoid all the mess which comes with that patch? The
> > approach of letting global state be modified in a random manner is
> > just doomed.
>
> Well doomed sounds bad :-) ... and I think I now agree that we should
> get rid of global state and have polling vs. CMCI mode be per-cpu. It
> means that it will take fractionally longer to react to a storm, but
> on the plus side we'll naturally set storm mode on just the cpus
> that are seeing it on a multi-socket system without having to check
> topology data ... which should be better for the case where a noisy
> source of CMCI is plaguing one socket, while other sockets have some
> much lower rate of CMCI that we'd still like to log.
I thought more about it - see my patch. So I have a global state now
as well, but it's only making sure that stuff stays in poll mode as
long as others are in poll mode. That's good I think as you avoid the
following:
cmcis which affect siblings or a socket are delivered to all affected
cores, but only one core might see the bank. So all others would
reenable fast and then switch back to polling because the storm still
persists. This would ping pong so, we probably want to avoid it.
Ideally the storm_on_cpus variable should be per socket and not system
wide, but we can do that when it really becomes an issue.
Thanks,
tglx
next prev parent reply other threads:[~2012-05-24 18:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 2:32 Chen Gong
2012-05-23 10:09 ` Thomas Gleixner
2012-05-23 17:01 ` Luck, Tony
2012-05-23 18:58 ` Thomas Gleixner
2012-05-23 20:53 ` Luck, Tony
2012-05-24 2:23 ` Chen Gong
2012-05-24 6:00 ` Borislav Petkov
2012-05-24 9:54 ` Chen Gong
2012-05-24 10:02 ` Thomas Gleixner
2012-05-24 10:01 ` Thomas Gleixner
2012-05-24 10:48 ` Borislav Petkov
2012-05-24 17:34 ` Borislav Petkov
2012-05-24 10:12 ` Thomas Gleixner
2012-05-24 16:27 ` Luck, Tony
2012-05-24 18:18 ` Thomas Gleixner [this message]
2012-05-23 10:11 ` Borislav Petkov
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=alpine.LFD.2.02.1205242013490.3231@ionos \
--to=tglx@linutronix.de \
--cc=bp@amd64.org \
--cc=gong.chen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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
Powered by JetHome