nanook@eskimo.com (Robert Dinse) wrote on 01.07.00 in <Pine.SUN.3.96.1000701211056.260K-100000@invisible.eskimo.com>:
> You say, "Linux adoptes features based SOLELY on technical merit."
> Then later in that very same message, you say, "Like you or not but
> aesthetic ground is THE ONLY decision ground for Linus."
>
> Which is it, aesthetics which are subjective and arbitrary and often
> in complete conflict with technical merit, or truely technical merit,
> which is quantifiable and objective?
There is a school of thought that claims the two are one and the same,
*and* that technical merit is *not* "quantifiable and objective" *in
general* (though it's certainly possible to measure the performance of a
solution, all measures of maintainability I have ever heard about were
deeply flawed, for example). And of course there's nothing that says
aesthetics can't cover performance.
I certainly subscribe to that view. It seems that Linus and the other core
kernel hackers also do.
> If more people TRIED the patch, even if frequent reschedualing is the
> wrong way to achieve low latency, they would understand the benefits to
> the general community, not just to the select group that has a need for
> those special applications.
And what is that supposed to achieve?
*Linus* already understands the benefits.
(In fact, if there's any specific technical direction Linus has been known
for, it's pushing the importance of latency over throughput! Anyone
remember the network latency discussions, for example? Or the *many*
interactive performance debates?)
> I am trying really hard to understand this, honest I am. And perhaps
> I am just not sufficiently imaginative. But if rescheduals are added
> intelligently, not in the middle of a piece of critical code where a lock
> is being held, I don't understand how this can create races that don't
> already exist and wouldn't surface in an SMP environment without the
> reschedual.
The main (not only) problem is identifying those secure points. (There's
also the problem that a long-running code path may not *have* a secure
point somewhere in the middle. At which time you *have* to think about
changing your algorithm anyway.)
Mostly, this is something that can be solved incrementally much better
than in one single brute-force approach.
The way I understand it, Ingo's patch is essentially one such brute-force
approach. It's one way of finding most problem spots fairly quickly, but
(1) the individual solutions probably are sub-optimal in many cases, and
(2) it is not even clear that all of them are actually necessary. I know
from experience that this type of fix often has the problem that you fix
where you think is the problem, then see another problem that was
invisible before, but fixing *only* that other problem might have fixed
your first problem, too - and unless you explicitely test for this, you
won't know.
So: IMAO, the right way is (1) fix those areas where you can see that
there is obviously a local problem (because you'll never find a way
without doing that anyway), (2) retest to find what problem spots are
left, (3) *study* those places, (4) experiment with various solutions to
find the best, (5) lather, rinse, repeat, (6) decide to abort when there
is no more good solution to be found.
This is not a fast algorithm. It is, however, IMAO a necessary one.
Also, it seems to be the algorithm Linus has already decided on.
> It was never my intention to convince Linux that said patch was not a
> piece of crap. My intention was/is to point out that, it has value to the
> general community above and beyond those applications for which low
> latency is critical.
Applications for which latency is critical include nearly all interactive
applications. Linus has known this for a very long time, as anyone
following l-k cannot help but notice.
> These things are being worked on though, but will latency issues be
> worked on at all if some suboptimal solution is not part of the kernel?
They have so far.
> Well, I think that would depend on whether being pretty or being
> functional was the major design goal. With respect to Linux, I am sure
> you are right on this note.
You seem to think there is some kind of conflict. I think both of these
are necessary for the other.
MfG Kai
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST