Messages in this thread | | | Subject | Re: Low Latency | Date | Mon, 03 Jul 2000 20:34:53 -0400 | From | Horst von Brand <> |
| |
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/
| |