lkml.org 
[lkml]   [2000]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux scheduler, overscheduling performance, threads
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.146 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site