lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)

On Sun, 20 Sep 1998, Linus Torvalds wrote:

> On Sun, 20 Sep 1998, Gerard Roudier wrote:
> >
> > On architectures where consistency is maintained between Hardware
> > Interrupt Levels and CPU Execution Levels with regards to interruptible
> > code, you can design kernel data structures so that the actual execution
> > Level ensures integrity without additionnal synchronisation. When the
> > hardware does not implement such a mechanism or when SMP is not consistent
> > with it, you may want to implement it from software, but even, in the case
> > it is feasible, such an approach can only be bad for latency and
> > performances.
>
> This is completely and utterly untrue in SMP environments.

Agreed and I did mention the problem. Sorry for my bad english. :(

> In SMP, there is only _one_ primitive that makes sense, and trust me,
> SPL-levels aren't even close. The one primitive that makes sense is
> spinlocks with a local disable function (ie disable either interrupts
> locally or disable bottom half handling or similar on that one CPU).

If you would have read the rest of my mail, you would know that I consider
SPL stuff to lead to bad designed drivers and sub-systems.

> Really. The notion of blocking an interrupt (or a group of them) is just
> very fundamentally and inherently broken as a synchronization primitive.

It works for *BSD systems (at least for UP). This abstraction seems to
prevent from reentering interrupt handlers of a given sub-system. I donnot
know of the code, but they probably have to try to always run with
interrupt enabled and handle all this stuff from software. Let me guess
that they must actually mask PCI interrupts in order to avoid permanent
interrupts and that shared PCI IRQs may have some unexpected interactions
between sub-systems when some are not fast for interrupts or some
sub-systems enjoyed spl's without moderation.

> And this is true even when the hardware _does_ support SPL-like things.
> For example, it's very obvious that intel designed the IO-APIC as being a
> "global SPL" thing. It's also very obvious that it's completely
> irrelevant, and that they shouldn't even have tried: even if you block
> interrupts you have to then synchronize with the other CPU's to make sure
> there aren't any already executing interrupt threads.

I tried to understand how the IO-APIC/LOCAL-APIC stuff works from Intel
specs months ago but did'nt really succeed. :)
I trust your analyzis on this point.

> In essense, even with spl-levels you still end up having to do the
> synchronization anyway. As such, you're _much_ better off just forgetting
> about spl, and do the synchronization right from the start.

> Linus
>
> [ And yes, I'm aware that we don't reasonably scale to tons of CPU's right
> now. My point is that I want to head off any stupidity wrt interrupt
> handling long before somebody gets too attached to it. Just say NO to
> anything but spinlocks when it comes to device driver interactions. ]

YES, SIR!

Regards,
Gerard.


-
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:44    [from the cache]
©2003-2011 Jasper Spaans