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, 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.

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).

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

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.

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. ]


-
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    [W:1.196 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site