Paul Barton-Davis writes:
> >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.
Really? It's been a while since I've done any measurements, but IIRC,
I was getting IRQ latencies of about 20 us on a 386 back in September
1998. Sure, sometimes it would be much worse (other drivers blocking
IRQs), but it indicated the basic code path was short.
Context switches were < 25 us.
> 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.
Do you have numbers showing that things have gotten much worse as time
has progressed? And by how much? If so, it's worth looking into.
It may be some slowdowns are due to greater emphasis on correctness,
as bugs and races have been found. However, efforts like removing the
big kernel lock should be improving the situation.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:11 EST