Messages in this thread | | | From | teamwork@freemail ... | Subject | Scheduling Times --- Revisited | Date | Sat, 26 Sep 1998 10:20:29 GMT |
| |
Hello Linus, Larry & Richard,
There have been much arguments about means, medians, variances, cache hits, and the noises has cover up the real issue that we should all talk about, that is:
"Are we going to make Linux the best there is, or are we here to argue back and forth about things that do not contribute to the betterment for Linux."
Let us assume that Richard's tests are not accurate. Let us also assume that Mr. Gooch is getting such wide variances in the his results because of the overheads [like Linus once implied.]
Let us even agree to Larry's point that there is nothing wrong with the current implementation, that there is no alarming slow down even when Linux does a 24-deep process.
Having assumed all that, something that Larry said to Richard needs to be dealt with:
"Have you ever considered that maybe you're worrying about a problem that doesn't exist?"
How do you know that, Larry?
The problem _may_ not be staring at our collective faces right now, but there is no proof it doesn't exist. What Richard asked was reasonable, that is, to improve the context-switching time, and to have a separate scheduller for the RT-tasks.
Larry, you have ardently argue against changing anything, perhaps I am too dense, so please educate me again.
You said:
"The harm is in making changes at all without being able to justify them."
_Justify_ ??
Exactly what conditions is _qualified_ under your "justification" rule, Larry?
Do we have to wait until something that is obviously broken before we start to fix it?
While Linux's current set up is not "broken" as the needs may not yet arise, it doesn't tax us all too much to make Linux ready for future tasks that may require minimal latency in context switching that Linux right now can't yet provide.
Ultimately everything boils down to this:
Do we have to wait until a problem arises before we fix things?
Or do we prepare Linux for future possibilities?
While I fully understand that we can't prepare Linux for _All_ future possibilities, in this case Richard has brought up a valid case that signifies one of the many future uses for Linux machines.
Why can't we try our best to prepare Linux to meet and/or exceed the challenges that are ahead of us, instead of arguing back and forth of meaningless means, variances, medians, and the like? What's wrong with putting our priority in order, huh?
I know, I know, this is a question of philosophy, which only Linus the *GOD*, will decide.
Respectfully, Pete teamwork@freemail.c3.hu
- 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/
| |