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?
>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.
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.
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.
>Unfortunatelly it NOT just expose races. It can CREATE races where
>otherwise there were no races.
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.
>About Solar Designer's patches you can scan lklm archives - it was
>investigated quite deep few times and conclusion was that non-executable
>stack it CAN break some things and (more important) it DOES NOT help to
>protect system in long terms.
Well, first of all Solar Designer's patches add a lot of security
related functionality aside from the non-executable stack. Which of these
functions you decide to use becomes a configuration option, so if you
really need trampolines, you can configure not to include the
non-executabel stack, or you can include an option that tries to
auto-detect them.
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.
Particularly if you aren't using precompiled binaries. And other aspects of
the patch are not as easily gotten around. Stackguard which you advocate as a
substitute is also not absolute, that is, it can be gotten around. And since
it's implimented in the compiler, and only with an old version of GCC, you're
forced to use an antiquated compiler to take advantage of it and you only gain
advantage on binaries you compile. Most security mechanisms are not absolute.
>You obviously do not understood what this patch does good enough so you
>can not convince Linus that said patch is not peice of crap.
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.
>RD> Like the VM system, or the TCP stack, or the schedualer, or the
>RD>disk I/O subsystem, or the ISDN code, or ....
>
>Unfortunatelly these things are already in kernel and pulling crap out of
>kernel is MUCH harder then denying it in first place. Fell free to clean
>up mentioned things, though.
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?
>RD> It's not my code but I think the functionality Mingo created is
>RD> worthwhile.
>
>In short terms - yes. In long terms... I doubt it.
Why do you feel that low latency won't be worthwhile in the long
term? I think the trend is more towards multi-media applications where
latency is critical, not away from them.
>RD> Given a choice between pretty or functional, I tend to opt for
>RD> the latter.
>
>And this mean you CAN NOT be maintainer for OS. It's BAD thing for such
>person.
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 can not reshdule at random place in kernel.
I agree. But were Mingo's choice of reschedual points random?
>P.S. It IS possible that latency issue is important enough for such
>effort.
This is really the main point indirectly of my original post. If it
only had utility to a handful that benefit from low latency, those with
special applications to which it is critical, then it would not be worth
the effort. It does have general utility because it improves the
responsiveness and feel of the kernel even for the user that does not have
critical real-time low latency needs. And that makes it more worth the
effort.
-
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