From: Russ Anderson <rja@sgi.com>
To: Alex Chiang <achiang@hp.com>,
tony.luck@intel.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
stable@kernel.org, linux-ia64@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: rja@sgi.com
Subject: Re: [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq handlers on offline CPUs"
Date: Mon, 09 Feb 2009 23:52:33 +0000 [thread overview]
Message-ID: <20090209235233.GA6235@sgi.com> (raw)
In-Reply-To: <20090209233324.GE3939@ldl.fc.hp.com>
On Mon, Feb 09, 2009 at 04:33:24PM -0700, Alex Chiang wrote:
>
> I'm a little closer to understanding why the original revert
> survives my test though.
>
> It seems that during ia64_process_pending_intr(), we will skip
> TLB flushes, and IPI reschedules.
>
> Vectors lower than IA64_TIMER_VECTOR are masked (because we raise
> the TPR), meaning we won't see CMC/CPE interrupts or perfmon
> interrupts.
>
> This leaves only IPIs and MCA above IA64_TIMER_VECTOR. The kernel
> doesn't actually send many IPIs to itself, so in practice, we
> almost never see those. If we receive an MCA interrupt, well, we
> have more problems to worry about than taking a CPU offline (and
> whatever implications it may have on RCU). So I'm not concerned
> there.
Keep in mind there are recoverable MCAs on ia64. It should
be a rare condition to have an MCA surface while taking a CPU
offline, but it could happen.
My main point is to make sure people do not assume that an MCA means
the system is going down.
> The upshot is that in practice, we pretty much ever only need to
> handle the timer interrupt.
Thanks.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
WARNING: multiple messages have this Message-ID (diff)
From: Russ Anderson <rja@sgi.com>
To: Alex Chiang <achiang@hp.com>,
tony.luck@intel.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
stable@kernel.org, linux-ia64@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: rja@sgi.com
Subject: Re: [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq handlers on offline CPUs"
Date: Mon, 9 Feb 2009 17:52:33 -0600 [thread overview]
Message-ID: <20090209235233.GA6235@sgi.com> (raw)
In-Reply-To: <20090209233324.GE3939@ldl.fc.hp.com>
On Mon, Feb 09, 2009 at 04:33:24PM -0700, Alex Chiang wrote:
>
> I'm a little closer to understanding why the original revert
> survives my test though.
>
> It seems that during ia64_process_pending_intr(), we will skip
> TLB flushes, and IPI reschedules.
>
> Vectors lower than IA64_TIMER_VECTOR are masked (because we raise
> the TPR), meaning we won't see CMC/CPE interrupts or perfmon
> interrupts.
>
> This leaves only IPIs and MCA above IA64_TIMER_VECTOR. The kernel
> doesn't actually send many IPIs to itself, so in practice, we
> almost never see those. If we receive an MCA interrupt, well, we
> have more problems to worry about than taking a CPU offline (and
> whatever implications it may have on RCU). So I'm not concerned
> there.
Keep in mind there are recoverable MCAs on ia64. It should
be a rare condition to have an MCA surface while taking a CPU
offline, but it could happen.
My main point is to make sure people do not assume that an MCA means
the system is going down.
> The upshot is that in practice, we pretty much ever only need to
> handle the timer interrupt.
Thanks.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
next prev parent reply other threads:[~2009-02-09 23:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 18:13 [PATCH v2 0/2] ia64: prevent irq migration race in __cpu_disable Alex Chiang
2009-02-09 18:13 ` [PATCH v2 0/2] ia64: prevent irq migration race in __cpu_disable path Alex Chiang
2009-02-09 18:16 ` [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq Alex Chiang
2009-02-09 18:16 ` [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq handlers on offline CPUs" Alex Chiang
2009-02-09 21:17 ` [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq Alex Chiang
2009-02-09 21:17 ` [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq handlers on offline CPUs" Alex Chiang
2009-02-09 23:33 ` [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq Alex Chiang
2009-02-09 23:33 ` [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq handlers on offline CPUs" Alex Chiang
2009-02-09 23:52 ` Russ Anderson [this message]
2009-02-09 23:52 ` Russ Anderson
2009-11-12 22:40 ` [APPLIED] [PATCH v2 1/2] Revert "[IA64] prevent ia64 from invoking irq Tony Lindgren
2009-02-09 18:16 ` [PATCH v2 2/2] ia64: Remove redundant cpu_clear() in __cpu_disable Alex Chiang
2009-02-09 18:16 ` [PATCH v2 2/2] ia64: Remove redundant cpu_clear() in __cpu_disable path Alex Chiang
2009-02-10 12:36 ` [PATCH v2 0/2] ia64: prevent irq migration race in Paul E. McKenney
2009-02-10 12:36 ` [PATCH v2 0/2] ia64: prevent irq migration race in __cpu_disable path Paul E. McKenney
2009-02-10 16:11 ` [PATCH v2 0/2] ia64: prevent irq migration race in Alex Chiang
2009-02-10 16:11 ` [PATCH v2 0/2] ia64: prevent irq migration race in __cpu_disable path Alex Chiang
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=20090209235233.GA6235@sgi.com \
--to=rja@sgi.com \
--cc=achiang@hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=stable@kernel.org \
--cc=tony.luck@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.