lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Low Latency
In <Pine.SUN.3.96.1000701211056.260K-100000@invisible.eskimo.com> Robert Dinse (nanook@eskimo.com) wrote:
> 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."

There are no contradiction, can you believe it or not :-)

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

Ok. "Technical merit". What's "technical merit" ? If we want to grade thing
by "technical merit" we need some way to measure that "technical merit", right ?
Ok. So far ultimate way to measure "technical merit" was via Linus's
aesthetic sense. You may think it's poor way to measure "technical merit"
but it's how it's measured for linux. Last few years showed that this
method works quite well and so we need REAL STRONG proof that any other way
it better.

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

Then what EXACTY this
-- cut --
Why can't this be made into a configuration option?
-- cut --
means ????

> I sure would like to see the latency issue get addressed without the need to
> apply a patch for each release.

Yeah ? And THIS IS not try to convinience Linus to include patch ? Gosh.

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

Linus feel it's worthwhile goal. It's enough. What we need now is not
"more peoples who would understand the benefits to general community"
but "more peoples who can generate more clean CODE to lower latency".
It's diffrent thing.

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

And if there are exist good proof that such functions are INDEED non-fixable
in any other way then via addition of pre-emption points and that we INDEED
NEED such latency objectives in THAT TIME this ONE pre-emption point is
justified and not arbitrary anymore. We have such proof for read/write
user-copy code. All other points are arbitrary (till not proved otherwise).

> In those cases, reschedualing is the only way you're going to achieve
> latency objectives.

Not exactly. Other way is to redesign some linux's subsystem in such way that
said functions are not needed in first place. It's hard but not harder then
to maintain code with 10'000 pre-emption points. Where the border lies ?
Where Linus will put it as usual :-)

> 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 some will not: "X number of bytes squeezing into the ISA bus takes
Y amount of time."

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

You [almost] 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.

1. There are MUCH less locks in UP kernel then in SMP kernel. EXACTLY since
resheduling can not occur in arbitrary point.
2. Yes, you are right about critical code. You just forget one simple thing:
critical code is not one blob. It can call other functions. Thus such
pre-emption points add additional load on maintainers: now they should
keep in mind that some functions can not be called from critical code
anymore - directly or indirectly. You do not need 10'000 pre-emption
points to make maintainers life miserable. You need way less.

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

Translation: Solar Designer's patches add A LOT OF band-aids. Hmm. And THIS
means it should be included in mainstream kernel ? Are you joking ot what ?

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

Non-exec stack WILL NOT be included in kernel. Linus said it clear enough.
Other parts can be considered. Some of them can be in fact not even band-aids.
But who should do this separation and clean up ?

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

Translation: it'll help us for few weeks and will add cruft in kernel FOREVER.
No, thnx.

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

It will not sit in non-swapable kernel space. It will not add load on kernel
maintainers. It's big win.

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

Then port stackguard on new GCC and do not use precompiled binaries. Not kernel
issue at all. What's feasible to do in userspace, should be done in userspace.

> Most security mechanisms are not absolute.

VERY true. And even less security mechanisms are good enough to go in kernel.

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

And THAT'S why you said it does not create deadlocks ? And THAT'S why you
argued that it must be an option in standart kernel ? Gosh...


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

Yeah, they will. If there are exist some peoples who NEED low latency then we
can hope that there will be some peoples who NEED it badly enough to dig deep
in kernel and develop proper solution. If some suboptimal solution is part of
kernel then chance to find such person will be MUCH lower - what for if it's
already handled somehow ?

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

It was my words. Perhaps I've formulated it slightly non-optimal. I've talked
not about low-latency needs but about patch here. So far we have only one way
to get low-latency: with said patches. And since it's "the only game in town"
we have to live with it. But it's quite possible that in long terms this
problem will be solved in some other, completely unrelated way. If deep and
carefull investigation of problem will show that it's THE ONLY way to handle
low-latence problem THEN we can think about it's adoption by mainstream
kernel.

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

It's fate of ANY big (destined to be alive tens of years) project. If you
are chosing functionality over clear design then suddenly in just few years
(sometimes even LESS THEN IN YEAR) you have system without functionality and
without clean design: "this beast HAS all bells and whisltes imaginable at
akk! just you need 100000000MHz processor and 100000GiB of RAM to run it"
(little exaggeration but you got the idea).

>>You can not reshdule at random place in kernel.

> I agree. But were Mingo's choice of reschedual points random?

Of course :-) I've not seen prof of otherwise in said patch and without
proof it's so by default.

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

It does not make adoption of said patch worthwhile. And said effort DOES NOT
belong to 2.4 kernel in code-freeze phase. It's 2.5 project (if there are
enough volunteers, of course).

P.S. You raised quetion about adoption of low latency patch in the same letter
as question about Solar Designer's patch thus showing that you are clueless:
it was discussed quite a few times why Solar Designer patches are not acceptable
for mainstream kernel and if you think low latency patch is somewhat like
Solar Designer patch that why the hell you STILL asking about it's inclusion ?




-
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:1.011 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site