>Linus has shown he's receptive to patches that make sense in a broader
>context and are clearly correct/worthwhile, even if a bit "tasteless".
>I wouldn't worry about the mainstream kernel getting slower due to an
>"easy" option of using RTLinux. It seems to me the kernel keeps
>getting faster in many areas. Kernel hackers are speed freaks. It's a
>matter of pride to keep the kernel fast (yet still elegant).
although this certainly appears to be the case in general, it hasn't
been true of latency. Not only is 2.4.0-anything worse than 2.2, but
Linux is probably the slowest of any OS that anyone I know has looked
into when it comes to return-from-interrupt-driven scheduling. it
could be that this is because nobody has bothered to pay much
attention to this issue. if so, i just hope that these exchanges will
do something to change that.
in fact, over the last 2-3 years that i've been following
linux-kernel, the only time that *general* concerns about scheduling
latencies have come up seem to have been at the instigation of someone
doing audio or video work. there's been a lot of attention paid to the
minutae of schedule(), but vastly less to the basic question of when or
how often it gets called. this is my impression, at least.
>Remember that keeping reasonable control over latencies is good for
>the general case as well. So these issues won't be ignored.
historically, they *have* been ignored, at least as a practical
matter. i doubt that anyone was trying to ignore them, but the result
has been incredibly long delays in scheduling under many common
situations. we're not talking about mindcraft/finessable differences
here, but factors of 5-100.
>The issue is not whether IRIX is preemtive or not. The issue is the
>cost of that preemption.
No, I was just using it as a demonstration of another way to fix the
problem. I wasn't arguing that Linux should do that.
>Well, from what I've noticed of Larry's debating style, he probably
>figures since you're the one wanting to make a change, it's up to you
>to demonstrate why it's justified and measure what the costs are.
I wasn't referring to anything he said about Linux. I was referring to
his willingness to take up some heresay about BeOS that came with no
numbers, no description, just a vague claim that "its getting
slower". In terms of its ability to get the equivalent of SCHED_FIFO
threads back on the processor after an interrupt makes them runnable,
this is not, AFAIK, true.
--p
-
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 : Fri Jul 07 2000 - 21:00:12 EST