Messages in this thread | | | Subject | Re: Linux scheduler, overscheduling performance, threads | Date | Sun, 23 Jan 2000 12:41:06 -0300 | From | Horst von Brand <> |
| |
Brian Hurt <bhurt@talkware.net> said: > This discussion is rapidly degenerating into a "does too!" "does not!" > match. So let me turn the question around. Assume, for a moment, that a > patch for Linux existed which did two things: > 1) Ran signifigantly faster for large run queues- for example it switched > from the current O(n) algorithm to an O(log n) algorithm. > 2) Ran slower than the current scheduling algorithm for short run > queues. > And the patch had no other effects on the kernel at large and was > otherwise well written, etc.
> Am I right in assuming that wether the patch would be accepted would > depend upon how much slower it made the common case? Obviously, if it > made the common case no slower, no one would mind putting it in the > kernel. On the other hand, if it made the common case a million times > slower, there is no way it'd ever get into the kernel, and rightfully so. > Where (roughly) inbetween is the breakpoint?
When it doesn't make runqueues of length 1 (typical, _optimal_ case) slower at all. OTOH, this happens once a timeslice, let's say 5 to 100 times a second, so it is simply not performance critical -- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viña del Mar, Chile +56 32 672616
- 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/
| |