Scheduling Times --- Revisited

teamwork@freemail.c3.hu
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/