Messages in this thread | | | Date | Wed, 8 Mar 2000 19:42:08 -0800 | From | Richard Henderson <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
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/
| |