On Thu, Mar 09, 2000 at 04:09:45AM +0100, Andrea Arcangeli wrote:
> >Each cpu has its own interrupt mask register, so the actual interrupt
> >handler needn't worry about communicating with other processors.
>
> Yes, but we definitely need the per irq-desc locking to avoid to run the
> irq handler on two CPUs at the same time.
Yes, we do need the irq-desc lock. I'd been talking about the
interrupt controler lock. Sorry for being imprecise.
> 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.
> 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.
I do see a use in 3c59x.c, (is that what you really meant?) in
vortex_timer, but that looks like it's used for timeout processing
e.g. for media type selection. Which seems definitely off the
critical path.
> I think using IPI for synchronization is a loss even if possible thing to
> do. enable_irq/disable_irq should be really fast.
Please show me where time-critical disable_irq happens. I don't
understand why it is necessary.
> (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.
> 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.
r~
-
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