All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Robert Richter <robert.richter@amd.com>,
	ying.huang@intel.com, Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/9] x86, NMI: Remove DIE_NMI_IPI and add priorties to handlers
Date: Wed, 01 Dec 2010 19:53:42 +0100	[thread overview]
Message-ID: <1291229622.32004.1886.camel@laptop> (raw)
In-Reply-To: <20101201184128.GB6478@lenovo>

On Wed, 2010-12-01 at 21:41 +0300, Cyrill Gorcunov wrote:
> On Tue, Nov 30, 2010 at 05:27:25PM -0500, Don Zickus wrote:
> > When re-ordering how the NMI handles its callbacks, a conversation started
> > asking what DIE_NMI_IPI meant.  No one could answer it.
> 
> It should have came from commit
> 
>  | commit c4b2bffee2a4115fed2825530f2b906ee2f17bd7
>  | Author: Andi Kleen <ak@suse.de>
>  | Date:   Fri Jan 23 18:46:40 2004 -0800
>  |
>  |   [PATCH] x86-64 merge
>  |   
>  |   Mainly lots of bug fixes and a few minor features. One change is that
>  |   it uses drivers/Kconfig now like i386. This requires a few minor changes in
>  |   outside Kconfig files which I am sending separately.
>  ...
> 
> Andi do you remember what the initial idea was? Didn't find any user of it
> even in this old commit. Just curious.
> 
> > 
> > Noticing that is was wasteful to call the die_chain a second time with just
> > another argument, DIE_NMI_IPI, it was decided to nuke it and add priorities
> > to the die_chain handlers to maintain existing behaviour.
> > 
> > This patch replaces DIE_NMI_IPI with the appropriate option, mostly DIE_NMI.
> > Then it adds priorities to those handlers, using a globally defined set of
> > priorities for NMI.
> > 
> > The thought is eventually we will just switch the nmi handlers from the
> > die_chain to something more nmi specific.
> > 
> > Signed-off-by: Don Zickus <dzickus@redhat.com>
> > ---
> 
>  Don, maybe switching to say new chains like chain_perf and friends would be
> more readable/clean? I'm not against this patch by any means, but just a thought ;)

Its a single event (NMI) so we only need a single notifier list, the
current one seems to be just fine.


  reply	other threads:[~2010-12-01 18:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-30 22:27 [V3 PATCH 0/9] x86, NMI: give NMI handler a face-lift Don Zickus
2010-11-30 22:27 ` [PATCH 1/9] x86, NMI: Add NMI symbol constants and rename memory parity to PCI SERR Don Zickus
2010-11-30 22:27 ` [PATCH 2/9] x86, NMI: Add touch_nmi_watchdog to io_check_error delay Don Zickus
2010-11-30 22:27 ` [PATCH 3/9] x86, NMI: Rewrite NMI handler Don Zickus
2010-11-30 22:27 ` [PATCH 4/9] x86, NMI: Remove DIE_NMI_IPI and add priorties to handlers Don Zickus
2010-12-01 18:41   ` Cyrill Gorcunov
2010-12-01 18:53     ` Peter Zijlstra [this message]
2010-12-01 19:01       ` Cyrill Gorcunov
2010-12-01 21:30     ` Andi Kleen
2010-12-01 21:35       ` Cyrill Gorcunov
2010-11-30 22:27 ` [PATCH 5/9] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU Don Zickus
2010-11-30 22:27 ` [PATCH 6/9] x86: only call smp_processor_id in non-preempt cases Don Zickus
2010-12-01 18:07   ` Cyrill Gorcunov
2010-11-30 22:27 ` [PATCH 7/9] x86: Avoid calling arch_trigger_all_cpu_backtrace() at the same time Don Zickus
2010-11-30 22:27 ` [PATCH 8/9] panic: ratelimit panic messages Don Zickus
2010-11-30 22:27 ` [PATCH 9/9] watchdog: touch_nmi_watchdog should only touch local cpu not every one Don Zickus
2010-12-22  3:16 ` [V3 PATCH 0/9] x86, NMI: give NMI handler a face-lift Huang Ying

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=1291229622.32004.1886.camel@laptop \
    --to=peterz@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=dzickus@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=robert.richter@amd.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 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.