LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: "Lu, Yinghai" <>
Cc: "Andi Kleen" <>, "Andrew Morton" <>,,
	"Luigi Genoni" <>,
	"Ingo Molnar" <>,
	"Natalie Protasevich" <>
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: <> (raw)
In-Reply-To: <> (Yinghai Lu's message of "Mon, 5 Feb 2007 12:54:13 -0800")

"Lu, Yinghai" <> writes:

> -----Original Message-----
> From: [] 
> 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

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


  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] <>
     [not found] ` <>
2007-02-02 18:02   ` System crash after "No irq handler for vector" linux 2.6.19 Eric W. Biederman
     [not found]     ` <>
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]             ` <>
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.' \

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