linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Borislav Petkov <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>, Andi Kleen <andi@firstfloor.org>
Subject: RE: [PATCH v3 0/3] Handle IST interrupts from userspace on the normal stack
Date: Wed, 19 Nov 2014 18:29:58 +0000	[thread overview]
Message-ID: <3908561D78D1C84285E8C5FCA982C28F32940EF2@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <cover.1416352397.git.luto@amacapital.net>

> NB: Tony has seen odd behavior when stress-testing injected
> machine checks with this series applied.  I suspect that
> it's a bug in something else, possibly his BIOS.  Bugs in
> this series shouldn't be ruled out, though.

v3 did 3.5x better than earlier ones ... survived overnight but died at 91724
injection/consumption/recovery cycles just now. Different symptom,
instead of losing some cpus, there was a fatal machine check (PCC=1
and OVER=1 bits set in the machine check bank). This might be from a
known issue.
Not sure if this was due to some improvement in the code, or because
I changed the system configuration by pulling out all the memory except
for that on memory controller 0 on node 0. Our BIOS team had told me
they'd seen some instability in the injection code on fully populated
systems.

I did instrument the synchronization in mce_start(). I was a bit worried
that with ever increasing numbers of cpus the 100ns delay between
pounding on atomic ops on mce_callin might not be enough. But it
seems we are not in trouble yet. Slowest synchronization recorded
took 1.8M TSC cycles. Mean is 500K cycles.  So my gut feeling that
the one second timeout was very conservative is correct.

-Tony

  parent reply	other threads:[~2014-11-19 18:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-18 23:15 [PATCH v3 0/3] Handle IST interrupts from userspace on the normal stack Andy Lutomirski
2014-11-18 23:15 ` [PATCH v3 1/3] uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME Andy Lutomirski
2014-11-18 23:15 ` [PATCH v3 2/3] x86, entry: Switch stacks on a paranoid entry from userspace Andy Lutomirski
2014-11-18 23:15 ` [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep Andy Lutomirski
2014-11-19 18:40   ` Linus Torvalds
2014-11-19 19:23     ` Andy Lutomirski
2014-11-19 19:29     ` Andi Kleen
2014-11-19 19:44       ` Linus Torvalds
2014-11-19 23:04         ` Andy Lutomirski
2014-11-19 23:23           ` Linus Torvalds
2014-11-19 23:32             ` Thomas Gleixner
2014-11-19 23:42               ` Linus Torvalds
2014-11-19 23:49             ` Andy Lutomirski
2014-11-19 23:59               ` Linus Torvalds
2014-11-20  0:13                 ` Andy Lutomirski
2014-11-20  0:37                   ` Linus Torvalds
2014-11-20  0:46                     ` Andy Lutomirski
2014-11-20  1:09                       ` Linus Torvalds
2014-11-20  1:11                         ` Andy Lutomirski
2014-11-20 10:28                       ` Borislav Petkov
2014-11-20 23:25                         ` Andy Lutomirski
2014-11-20  7:45                   ` Ingo Molnar
2016-02-29  5:27         ` Andy Lutomirski
2016-05-24  1:23           ` Andy Lutomirski
2016-05-24  1:48             ` Linus Torvalds
2016-05-24  2:09               ` Andy Lutomirski
2016-05-24  2:16                 ` Linus Torvalds
2014-11-19 18:29 ` Luck, Tony [this message]
2014-11-19 22:15 ` [PATCH] x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks Luck, Tony

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=3908561D78D1C84285E8C5FCA982C28F32940EF2@ORSMSX114.amr.corp.intel.com \
    --to=tony.luck@intel.com \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --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;
as well as URLs for NNTP newsgroup(s).