[lkml]   [1998]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] scheduler patch, faster still
Thus spake Larry McVoy (
> Furthermore, your suggested "fix" is completely specific to your
> application with short RT run queues. What happens if you have 10
> RT processes? Won't they have exactly the same "problem" that you
> are currently "fixing" by moving your processes off the run queue
> onto another queue? If that's the case, how can you possibly call
> it a RT queue - it only helps you. Shouldn't it really be called the
> Short_RT_Process_Queue_For_Mr_Goochs_Possible_Problem?

I don't understand why you are flaming him so badly.
I don't care if it fixes his problem or not. If it looks sensible and
actually speeds something up without slowing the common case down,
it's a good idea to integrate it.

One of the cornerstones of computer science is

Make the common case fast.

Your argumentation about long RT run queues is not a valid argument.
The common case is clearly to have an empty RT run queue or one with one
process (MP3 player) and people who want to do hard RT will want to use
RTLinux, anyway. The argument that it might not help long run queues is
like using NT because it might become more stable in a few years.

If the effects of his optimization is not measurable for typical
workloads, who cares? As long as it does not make the code obfuscated
or bloated or slower in the common case, it doesn't hurt.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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