[kernel] bug#40: "optimal" virtual IRQ support proposal

X-PA-RISC Linux-PR-Message: report 40
X-PA-RISC Linux-PR-Package: kernel
X-Loop: daniel_frazier@hp.com
Received: via spool by bugs@bugs.parisc-linux.org id=B.98297496512197
          (code B ref -1); Sat, 24 Feb 2001 00:48:01 GMT
Message-Id: <200102240039.QAA21779@milano.cup.hp.com>
X-Authentication-Warning: milano.cup.hp.com: grundler@localhost [127.0.0.1] didn't use HELO protocol
To: submit@bugs.parisc-linux.org
Date: Fri, 23 Feb 2001 16:39:00 -0800
From: Grant Grundler <grundler@cup.hp.com>

Package: kernel
Version: Oct2000
Severity: wishlist


------- Forwarded Message

To: Helge Deller <deller@gmx.de>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] /proc/interrupts 
Date: Wed, 18 Oct 2000 09:36:31 -0700
From: Grant Grundler <grundler@cup.hp.com>

Hi Helge!

Helge Deller wrote:
...
> 1. The until now used virtual IRQ's gets new numbers and increments in every 
> region by 32 for parisc32 and 64 for parisc64. The old IRQ regions 
> incremented by 256.

prumpf did something like this too.
It's better - but IMHO not "optimal".

I've been thinking about an "optimal" solution but haven't had a chance
to try it out. Here's my proposal:
o "invent" (yeah...I heard you, Carly! :^) a global "action" table.
o All IRQ allocation will get an "action" entry from the global table.
o And each IRQ region is a table of "action" pointers.
o "busy" IRQ region entries point to entries in the global "action" table.

"action" is a IRQ handler + arguments stuffed in a data structure.

Here are some examples of why I think this is "optimal":
o Older Workstations typically only need 10-20 "action" entries in
  2-4 IRQ regions.
o A500/C3000/J5000/L2000 might need about the same number of "action"
  entries but spread over 8 IRQ regions (4 CPU + 4 I/O Sapic).
o N-4000 might use over 60 entries in 22 IRQ regions!
  (12*4+8+5) That's 12 PCI Slots, 8 CPUs, and 5 built-in PCI devices
  spread over 8 CPU + 14 I/O Sapic.
o I don't know the limits of Superdome which was just announced.
  I've been asked about running linux on Superdome and my reply is
  first get it running on N-class (which isn't currently "in-plan"
  officially).

(Note: Even though today we only allocate one IRQ region for all CPUs,
in the future I'd like to see each CPU get it's own region.)

> 2. since we now shift by values of 5 (parisc32) or 6 (parisc64) bits, the 
> time needed to calculate the offsets may have changed. This needs to be 
> inspected.

I don't think this will be an issue.
I doubt a shift op takes longer (as measured in cycles) to shift more/less.


> 3. the new algorithm needs less memory than before.

yup - hypothetically by 4x or 8x. That's a good thing.

> By default I left the current behaviour in CVS, but you may activate the new 
> algorithm by changing the "#if 0" to "#if 1" in asm-parsic/irq.h and tell me 
> what you think.

That's cool...I'll enable it here for testing.
Remember - no news is good news :^)

thanks!
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253


------- End of Forwarded Message