lkml.org 
[lkml]   [2000]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new IRQ scalability changes in 2.3.48


On Tue, 29 Feb 2000, Roman Zippel wrote:
>
> First, isn't the irq probing stuff ISA related? I don't know of any other
> insanity that would need this.

Well, you're probably never interested in using a PCMCIA card either, are
you?

Or a number of other buses which actually do use probing.

> - I think the spinlock in there isn't really necessary, if real state
> changes are only happen from non-interrupt contexts. Everywhere else would
> be a "disable_irq(); spin_lock()" sequence sufficient.

"disable_irq()" is slow and requires the irq lock you want to get rid of
for synchronization: on pretty much every single architecture out there
interrupts are not "synchronous" wrt the core, so you cannot even disable
an interrupt without having extra synchronization (which is exactly what
the spinlock in do_IRQ gives you).

Many architectures do not have atomicity guarantees in SMP: you may end up
getting the same interrupt twice on two CPU's. The spinlock handles that
case too.

> - I doubt that all the status stuff is really necessary

Pretty much all of it IS required.

> - IRQ_REPLAY: Do interrupt handler require a real interrupt context or
> isn't a faked context sufficient?

They require that interrupts be on.

Hint:

CPU1 CPU2

disable_irq();

-- pending due to synchronization --
...
cli();
enable_irq();

which you'll have on pretty much any architecture.

> - IRQ_WAITING: it's only used for int probing and could IMO be moved to a
> special interrupt handler.

And the cost of it is what? Zero.

> - IRQ_DISABLED: We could implement an optimistic scheme, where we replace
> the action field with a dummy action, that keeps the interrupt disabled.
> enable_irq()/disable_irq() would be very cheap then and we disable the
> interrupt only when the really interrupt happens (and most of the time not
> at all for short disable_irq()/enable_irq() sequences).

Feel free to try it. It was discussed, but it's not trivial to do
correctly. You get the IRQ_PENDING problem even more clearly (ie it
becomes a problem even with well-designed interrupt controllers).

> - IRQ_PENDING: If I interpret the comment there correctly, the check is
> only necessary for faulty SMP hardware?

It's only necessary for hardware that doesn't work the way we want it to
work.

Which, sadly, is pretty much anything out there.

Linus


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.203 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site