[lkml]   [2006]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
Benjamin Herrenschmidt <> wrote:

> Well, genirq gives you more flexibility than the current mecanism so ...

No, it doesn't because the FRV arch contains its own mechanism and I can do
what ever I like in it.

genirq's flexibility comes at a price. Count the number of hooks in struct
irq_chip and struct irq_desc together.

> If I understand correctly, you need to do scray stuff to figure out your
> toplevel irq, which shound't be a problem with either mecanisms...

Yeah. I can't actually find out what source caused top-level IRQs. I have to
guess from looking at the IRQ priority and poking around in the hardware. I
got bitten that way too: at one point, I was peeking at the interrupt flag in
the serial regs, only to realise this was causing the driver to go wrong
because it cleared the interrupt requested flag in UART.

Obviously I'd rather not use IRQ priorisation to help multiplex irqs, but
unless I want a large polling set...

> Now, if you have funky cascades, then you can always group them into a
> virtual irq cascade line and have a special chained flow handler that
> does all the "figuring out" off those... it's up to you.

You make it sound so easy, but it's not obvious how to do this, apart from
installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
having those call back into __do_IRQ(). Chaining isn't mentioned in

> In general, I found genirq allowed me to do more fancy stuff, and end up
> with actually less hooks and indirect function calls on the path to a
> given irq than before as you can use tailored flow handlers that do just
> the right thing.

My code in the FRV arch has fewer indirection calls than the genirq code
simply because it doesn't require tables of operations. I can trace through
it with gdb and see them.

I built all the stuff that genirq does in indirections directly into the
handlers. It certainly has fewer hooks.

I attempted to convert it over to use genirq, and I came up with some numbers:

The difference in kernel sizes:

text data bss dec hex filename
1993023 77912 166964 2237899 2225cb vmlinux [with genirq]
1986511 76016 167908 2230435 2208a3 vmlinux [without genirq]

The genirq subdir all wraps up into this:

10908 3272 12 14192 3770 kernel/irq/built-in.o
1548 64 4 1616 650 arch/frv/kernel/irq.o
12456 3336 16 15808 3dc0 total

My FRV-specific IRQ handling wraps up into these:

480 488 0 968 3c8 arch/frv/kernel/irq-mb93091.o
4688 16 520 5224 1468 arch/frv/kernel/irq.o
1576 1152 16 2744 ab8 arch/frv/kernel/irq-routing.o
6744 1656 536 8936 22e8 total

There's a difference in BSS size in the main kernel that I can't account for,
but basically genirq uses 6.3KB more code and 1.8KB more initialised data, but
0.9KB less BSS. Overall, about 7.2KB more memory. I can shrink the BSS usage
in the FRV specific version by reducing the amount of space in the IRQ sources

So, again, why _should_ I use the generic IRQ stuff? It's bigger and very
probably slower than what I already have.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-07 12:01    [W:0.138 / U:16.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site