From: Grant Grundler <grundler@parisc-linux.org>
To: Matthew Wilcox <willy@debian.org>
Cc: PARISC list <parisc-linux@lists.parisc-linux.org>
Subject: Re: [parisc-linux] Proposal for implementing IRQ affinity
Date: Tue, 31 Aug 2004 12:06:35 -0600 [thread overview]
Message-ID: <20040831180635.GF20353@colo.lackof.org> (raw)
In-Reply-To: <20040831174357.GQ16196@parcelfarce.linux.theplanet.co.uk>
On Tue, Aug 31, 2004 at 06:43:57PM +0100, Matthew Wilcox wrote:
...
> > I'd rather see one global array (at least 256 entries) with the CPU
> > (and similar devices) getting a fixed number of consecutive entries.
> > We should probably reserve the first 16 entries for EISA/ISA support
> > like we did before.
>
> I'm not sure that's a good idea.
In linux-ia64-test-2.6.8.1/arch/ia64/kernel/iosapic.c:
unsigned int gsi_base; /* first GSI assigned to this IOSAPIC */
Looks like that's what ia64 is doing and I don't see a problem with it.
One of the drawbacks of IRQ regions is they are 32 or 64 entries wide
regardless of many are actually used.
> It would give the impression that all
> Lasi interrupts could be independently retargetted, which isn't true.
James mentioned this is a problem in his proprosal as well.
If we don't provide /proc/irq/<IRQ#>/smp_affinity, I don't see how
someone could be confused about it. Each IRQ entry will have
it's own function pointer to indicate if it supports redirection
or not.
I don't see how this related to single global array vs multiple arrays.
> Note that Dino is a little more advanced and has two IRR registers,
> so we could theoretically do some cool stuff with that ... but it's not
> important enough, IMO.
I agree.
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
next prev parent reply other threads:[~2004-08-31 18:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 3:31 [parisc-linux] Proposal for implementing IRQ affinity James Bottomley
2004-08-31 15:13 ` Bjorn Helgaas
2004-08-31 17:29 ` James Bottomley
2004-08-31 17:43 ` Bjorn Helgaas
2004-08-31 17:14 ` Grant Grundler
2004-08-31 17:43 ` Matthew Wilcox
2004-08-31 18:06 ` Grant Grundler [this message]
[not found] ` <20040831185750.GS16196@parcelfarce.linux.theplanet.co.uk>
2004-08-31 19:21 ` Grant Grundler
2004-08-31 19:28 ` Matthew Wilcox
2004-08-31 19:48 ` Grant Grundler
2004-08-31 21:26 ` Michael S. Zick
2004-08-31 22:19 ` Matthew Wilcox
2004-08-31 17:49 ` James Bottomley
2004-08-31 18:34 ` Grant Grundler
2004-08-31 19:44 ` James Bottomley
2004-08-31 20:21 ` Grant Grundler
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=20040831180635.GF20353@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=willy@debian.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.