LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Lu, Yinghai" <yinghai.lu@amd.com>
Cc: "Andi Kleen" <ak@suse.de>, "Andrew Morton" <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	"Luigi Genoni" <luigi.genoni@pirelli.com>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Natalie Protasevich" <protasnb@gmail.com>
Subject: Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.
Date: Mon, 05 Feb 2007 16:03:03 -0700	[thread overview]
Message-ID: <m1d54ow6l4.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907416@ssvlexmb2.amd.com> (Yinghai Lu's message of "Mon, 5 Feb 2007 12:54:13 -0800")

"Lu, Yinghai" <yinghai.lu@amd.com> writes:

> -----Original Message-----
> From: ebiederm@xmission.com [mailto:ebiederm@xmission.com] 
> Sent: Monday, February 05, 2007 12:37 PM
>
>
>>The only corner case I can see that might potentially happen is
>>"apic_in_service_vector() != irq_vector[irq]" and if that is the case
>>we don't want to migrate, because the precondition that we are in the
>>irq handler servicing the expected irq isn't true.
>
> Reuse vector could help in that case.

A little but you are still on the wrong cpu, and that corner case might
even be worth looking at on i386.  I haven't assessed what might go wrong
yet but the current strategy of migrating irqs is based in the interrupt
service routine being where new instances of that irq will be
delivered.

What I do know is all of this is a very narrow window, and insanely
hard to trigger with consequences that shouldn't hang the machine.
The only reason we are even getting a reasonable number of irqs being
in service and in the irr is because we are acking a level triggered
vector used by two irqs and then the pending irq retriggers.  Avoiding
that case would certainly be an efficiency improvement.

Basically I think it takes the alignment of several 1 in a million
chances before the code I posted will have problems with this
theoretical case.  

> In another case, if two irq are migrated from one cpu to another cpu.
> ack_apic_edge for irq2 could use get apci_in_servier_vector for irq1,
> and handle that to clear irr for irq1. instead of irq2.

Nope. irq routines are a stack.  if apic_in_service_vector could return
the wrong value.  ack_APIC_irq() which use the same information would
acknowledge the wrong irq.  If there was actually any danger of
mis-computing that information I would just pass it from the interrupt
service routine stash it in a per cpu variable and then read it out.
But the apic already has registers doing that, so I was lazy and used
what was available.  It should be the common case that we need that
information.


Eric

  reply	other threads:[~2007-02-05 23:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-05 20:54 Lu, Yinghai
2007-02-05 23:03 ` Eric W. Biederman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-05 23:33 Lu, Yinghai
2007-02-05 20:11 Lu, Yinghai
2007-02-05 20:37 ` Eric W. Biederman
2007-02-05 19:29 Lu, Yinghai
2007-02-05 19:59 ` Eric W. Biederman
     [not found] <200701221116.13154.luigi.genoni@pirelli.com>
     [not found] ` <200702021848.55921.luigi.genoni@pirelli.com>
2007-02-02 18:02   ` System crash after "No irq handler for vector" linux 2.6.19 Eric W. Biederman
     [not found]     ` <200702021905.39922.luigi.genoni@pirelli.com>
2007-02-03  0:31       ` [PATCH 1/2] x86_64 irq: Simplfy __assign_irq_vector Eric W. Biederman
2007-02-03  0:35         ` [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration Eric W. Biederman
2007-02-03  1:05           ` Andrew Morton
2007-02-03  1:39             ` Eric W. Biederman
2007-02-03  2:01               ` Andrew Morton
2007-02-03  7:32             ` Arjan van de Ven
2007-02-03  7:55               ` Eric W. Biederman
2007-02-03 14:31                 ` l.genoni
2007-02-03 10:01           ` Andi Kleen
2007-02-03 10:22             ` Eric W. Biederman
2007-02-03 10:26               ` Andi Kleen
2007-02-06  7:36           ` Ingo Molnar
2007-02-06  8:57             ` Eric W. Biederman
     [not found]             ` <200702061012.25910.luigi.genoni@pirelli.com>
2007-02-06 22:05               ` Eric W. Biederman
2007-02-06 22:16             ` Eric W. Biederman
2007-02-06 22:25               ` Ingo Molnar
2007-02-07  2:33                 ` Eric W. Biederman
2007-02-08 11:48                 ` Eric W. Biederman
2007-02-08 20:19                   ` Eric W. Biederman
2007-02-09  6:40                     ` Eric W. Biederman

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=m1d54ow6l4.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luigi.genoni@pirelli.com \
    --cc=mingo@elte.hu \
    --cc=protasnb@gmail.com \
    --cc=yinghai.lu@amd.com \
    --subject='Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.' \
    /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

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).