lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Low Latency
Date
From
Robert Dinse <nanook@eskimo.com> said:
> Khimenko Victor <khim@sch57.msk.ru> wrote five messages.
> Rather than clutter the list with responses to each individually, I will
> just pick key points and respond in one message:

> >What you do NOT undertood is HOW decisions are made.

> 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?

Aestetics in the narrow sense meant here is maintanability and "it just
feels like the right way". It is purely technical...

> >But if you think that it can change Linus's decision then you just
> >NOT understood HOW Linus make such decisions.

> I realize I haven't a snowballs chance in hell at convincing Linus to
> include Mingo patch. I sure would like to see the latency issue get
> addressed without the need to apply a patch for each release.

You (and a handful others) have such requirements, 90+% of users don't
care. More than enough reason not to include something which is a cost for
_everybody_, and is bad for maintainability (which will hurt even much more
in the longer run). Mingo's patch is just a quick kludge (he admitted as
much himself). Not much reason (except for sheer stubborness) to insist on
it, is there?

Linus (and others) have asked to find out where the bottlenecks are, and
see how to fix each one of them. If done cleanly in each case, with full
understanding of the tradeoffs and careful consideration if the costs are
justified in each case and all taken together, we'll all get a better
kernel in the end.

> 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.

Less stability, more overhead for everybody, loss of maintanability?

> I suspect that a real solution is going to fall somewhere inbetween.
> There will be functions of the kernel that take too long and that no
> matter how effeciently you code them, you can't make go faster or at
> least you can't make them go fast enough to meet latency objectives. In
> those cases, reschedualing is the only way you're going to achieve
> latency objectives. There will be other portions that can be made faster
> and more effecient. And of coarse, over time, CPU speeds will continue
> to increase and some problems will solve themselves.

And there will be cases where doing so hurts too much, and the latency has
to be left alone. And then there is the statement from bitter experience by
Larry McVoy that adding just a tiny overhead here won't hurt, and another
little bit over there can't do no harm, ... and one day you wake up and
have a clumsy dinosaur in your hands when you started out with a cheetah.

[...]

> With respect to the long term benefits; I have to disagree with you.
> It doesn't eliminate stack overflow exploits but it does make them more
> difficult.

Totally irrelevant.

> Particularly if you aren't using precompiled binaries.

Great attitude, that one: "As long as I am safe, let everybody else pay the
price. Screw them over at leisure."

Compiler switches, compiler version, program version will hardly ever
affect the stack frame layouts. What could change is jump targets, at most.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile +56 32 672616

-
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/

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