Thus spake Larry McVoy (lm@bitmover.com):> 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 andactually 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 oneprocess (MP3 player) and people who want to do hard RT will want to useRTLinux, anyway. The argument that it might not help long run queues islike using NT because it might become more stable in a few years.

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

Felix

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/