public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "KOCHI, Takayoshi" <t-kouchi@mvf.biglobe.ne.jp>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] [PATCH] dynamic IRQ allocation
Date: Tue, 30 Jul 2002 18:04:58 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590701905858@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905851@msgid-missing>

Thanks for comments.

On Mon, 29 Jul 2002 22:01:28 -0700
Grant Grundler <grundler@cup.hp.com> wrote:

> "KOCHI, Takayoshi" wrote:
> > This patch fixes the behavior and only allocates vectors
> > for existing pci_dev only.
> 
> Another approach is to defer allocating the vector until
> request_irq() registers the interrupt handler. That way,
> only devices that have drivers get interrupts.

But how to distinguish PCI irqs from others?
It seems that all PCI drivers pass its pci_dev structure
as the 4th argument of request_irq, but others won't
(for example, serial.c).

I thought allocating a new vector in request_irq() is another
level of dynamic allocation.

Once I took another approach and wrote a version that
allocates a new vector when a driver calls pcibios_enable,
but it turned out to be problematic because not all PCI
device drivers call pci_enable() at their startup.

It seems that, for i386, irq lookup is done in pcibios_enable()
(to be exact, pcibios_enable_irq() and other functions in
 arch/i386/kernel/pci-irq.c).  So drivers that doesn't
call pci_enable() are just working luckily (due to proper
setting by BIOS etc.)

> > As usual, interrupt sharing often imply performance
> > degradation and such a configuration should be avoided.
> 
> Another way to reduce/avoid sharing of vector table entries is to have
> multiple Vector Tables. Either one for each CPU or each node of
> a ccNUMA-like machine. I thought SGI's NUMA machines implement
> this already but haven't checked.

Yes, once Alan Mayer at sgi did the work.
But ccNUMA platforms can have various connection topology
and simply dividing vector table into the number of nodes
may not the best choice to do.

I think iosapic.c should be as generic as possible enough to
cover all IO SAPIC-based platforms and tuning for specific
ccNUMA platforms should be considered separately.


Thanks,
-- 
KOCHI, Takayoshi <t-kouchi@cq.jp.nec.com/t-kouchi@mvf.biglobe.ne.jp>



  parent reply	other threads:[~2002-07-30 18:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30  2:36 [Linux-ia64] [PATCH] dynamic IRQ allocation KOCHI, Takayoshi
2002-07-30  5:01 ` Grant Grundler
2002-07-30 18:04 ` KOCHI, Takayoshi [this message]
2002-07-30 22:14 ` Grant Grundler
2002-07-30 23:49 ` KOCHI, Takayoshi
2002-08-01  1:03 ` Grant Grundler
2002-08-02  0:39 ` KOCHI, Takayoshi
2002-08-02  6:04 ` David Mosberger
2002-08-02 15:56 ` Bjorn Helgaas
2002-08-02 16:32 ` David Mosberger
2002-08-02 17:45 ` KOCHI, Takayoshi
2002-08-02 18:58 ` Grant Grundler
2002-08-02 21:22 ` David Mosberger
2002-08-02 21:44 ` Bjorn Helgaas
2002-08-02 21:47 ` David Mosberger
2002-08-02 22:01 ` KOCHI, Takayoshi
2002-08-02 22:04 ` David Mosberger
2002-08-02 22:22 ` KOCHI, Takayoshi
2002-08-02 22:37 ` 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=marc-linux-ia64-105590701905858@msgid-missing \
    --to=t-kouchi@mvf.biglobe.ne.jp \
    --cc=linux-ia64@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox