On Wed, 8 Mar 2000, Richard Henderson wrote:
>> Hug, handler->enable_irq()/handler->disable_irq() are called for _each_
>> irq.
>
>Really? I thought ack/end was used in the interrupt handler,
>not disable/enable. I am talking about the hw_interrupt_type
>functions, not the dp264 functions of nearly the same name.
If you make the function disable_irq() slower, then handler->ack will be
so slow too. It's exactly the same SMP problematic as far I can tell. Same
for enable_irq() and handler->end. And I am talking about dp264 that is
the only alpha SMP platform I know (for the other non SMP platform I am
been careful to not add any controller lock).
>> And the real enable_irq()/disable_irq() is not less frequent than
>> interrupts in the 3c509 case (it may be the only operation while
>> transmitting data in UDP and that's an issue at least for multicasting).
>
>Really? I don't see any ocurrence of those functions in 3c509.c,
>nor in the net/ipv4 or net/core directories.
Oh, it got dropped in 2.3.x, sorry. It's still the case in 2.2.x though
(and it's certainly not changed because enable_irq now has two spinlocks
to pass).
>Please show me where time-critical disable_irq happens. I don't
>understand why it is necessary.
At least ide.c code does disable/enable for each request_fn.
>> (And it's not fully
>> clear to me how to solve the above race by using IPI btw :).
>
>I'll prototype some code that show you what I had in mind.
Ok, that's certainly welcome, thanks.
>> The current default for dp264 should be ok at lest for 2-way and maybe ok
>> for 4-way too (max number of CPU supported by dp264).
>
>Eh. It still seems sloppy.
2-way is fine here. 4-way I don't know yet :)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:15 EST