All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com>
Cc: "Brown, Len" <len.brown@intel.com>,
	sergio@sergiomb.no-ip.org,
	Kimball Murray <kimball.murray@gmail.com>,
	linux-kernel@vger.kernel.org, akpm@digeo.com, kmurray@redhat.com,
	linux-acpi@vger.kernel.org
Subject: Re: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision
Date: Thu, 27 Apr 2006 21:13:24 +0200	[thread overview]
Message-ID: <200604272113.24705.ak@suse.de> (raw)
In-Reply-To: <19D0D50E9B1D0A40A9F0323DBFA04ACC023B0B9F@USRV-EXCH4.na.uis.unisys.com>

On Thursday 27 April 2006 21:10, Protasevich, Natalie wrote:
> > 
> > >There are probably better ways to control 224 possible IRQs by their 
> > >total number instead of their range, and per-cpu IDTs are the better 
> > >answer to the IRQ shortage altogether. But just going back 
> > to the way 
> > >it was wouldn't be right I think.
> > >We were able to run 2 generations of
> > >systems only because we had this compression, other big systems 
> > >benefited from it as well.
> > 
> > I don't propose reverting the IRQ re-name patch and breaking 
> > the big iron without replacing it with something else that works.
> 
> Len, maybe it sounds dramatic and/or extreme, but how about getting rid
> of IRQs and just having GSI-vector pair.
> I intuitively think that would be possible (not that I have all the
> details lined up :)
> And this would probably take away confusing IRQ abstraction out once and
> for all? I think something like that is done in ia64.

x86 users are attached to their interrupt numbers I think back from the bad old
days with only 16 interrupts and interrupt sharing didn't work. We might have a revolt
in the user base if /proc/interrupts didn't display them anymore @)

But I guess using GSI/vector internally only would be fine.

-Andi


  reply	other threads:[~2006-04-27 19:13 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-27 19:10 [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision Protasevich, Natalie
2006-04-27 19:10 ` Protasevich, Natalie
2006-04-27 19:13 ` Andi Kleen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-09  5:14 Protasevich, Natalie
2006-05-09  5:14 ` Protasevich, Natalie
2006-05-09  4:25 Brown, Len
2006-05-09  4:25 ` Brown, Len
2006-05-09  3:10 Protasevich, Natalie
2006-05-09  3:10 ` Protasevich, Natalie
2006-05-08 21:51 Brown, Len
2006-05-08 21:51 ` Brown, Len
2006-05-08 18:37 Protasevich, Natalie
2006-05-08 18:37 ` Protasevich, Natalie
2006-05-06  6:42 Protasevich, Natalie
2006-05-06  6:42 ` Protasevich, Natalie
2006-05-06  6:18 Brown, Len
2006-05-06  6:18 ` Brown, Len
2006-05-04 16:42 Protasevich, Natalie
2006-05-04 16:42 ` Protasevich, Natalie
2006-05-04 16:04 Brown, Len
2006-05-04 16:04 ` Brown, Len
2006-05-04 22:41 ` Eric W. Biederman
2006-05-04 22:41   ` Eric W. Biederman
2006-05-04 15:33 Brown, Len
2006-05-04 15:33 ` Brown, Len
2006-05-04  5:07 Brown, Len
2006-05-04  5:07 ` Brown, Len
2006-05-04 15:31 ` Eric W. Biederman
2006-05-04 15:31   ` Eric W. Biederman
2006-05-02 23:52 Protasevich, Natalie
2006-05-02 23:52 ` Protasevich, Natalie
2006-05-02  7:41 Brown, Len
2006-05-02  7:41 ` Brown, Len
2006-05-02  7:46 ` Andi Kleen
2006-05-02  8:33 ` Eric W. Biederman
2006-05-02  8:33   ` Eric W. Biederman
2006-05-01 23:21 Brown, Len
2006-05-01 23:21 ` Brown, Len
2006-05-02  6:14 ` Andi Kleen
2006-05-02  6:57   ` Eric W. Biederman
2006-05-02  7:11     ` Andi Kleen
2006-05-02  7:39       ` Eric W. Biederman
2006-05-02  6:24 ` Eric W. Biederman
2006-05-02  6:24   ` Eric W. Biederman
2006-04-27 20:36 Protasevich, Natalie
2006-04-27 20:36 ` Protasevich, Natalie
2006-04-30 23:17 ` Eric W. Biederman
2006-04-30 23:17   ` Eric W. Biederman
2006-04-27 19:32 Brown, Len
2006-04-27 19:32 ` Brown, Len
2006-04-27 19:26 Protasevich, Natalie
2006-04-27 19:26 ` Protasevich, Natalie
2006-04-27 18:13 Brown, Len
2006-04-27 18:13 ` Brown, Len
2006-04-27 18:16 ` Andi Kleen
2006-04-26 14:00 Protasevich, Natalie
2006-04-26 14:00 ` Protasevich, Natalie
2006-04-25 19:53 Brown, Len
2006-04-25 19:53 ` Brown, Len
2006-04-26 12:58 ` Sergio Monteiro Basto
2006-04-26 13:17 ` Andi Kleen
2006-04-26 13:56   ` Kimball Murray
2006-04-26 14:01     ` Kimball Murray
2006-04-25 16:06 Kimball Murray
2006-04-25 16:06 ` Kimball Murray
2006-04-26 11:27 ` Andi Kleen

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=200604272113.24705.ak@suse.de \
    --to=ak@suse.de \
    --cc=Natalie.Protasevich@unisys.com \
    --cc=akpm@digeo.com \
    --cc=kimball.murray@gmail.com \
    --cc=kmurray@redhat.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergio@sergiomb.no-ip.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 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.