In <Pine.LNX.4.20.0007010907360.23375-100000@otter.mbay.net> John Alvord (jalvo@mbay.net) wrote:
JA> On 1 Jul 2000, Yoann Vandoorselaere wrote:
>> Robert Dinse <nanook@eskimo.com> writes:
>>
>> > On 1 Jul 2000, Yoann Vandoorselaere wrote:
>> > >
>> > > This thread is all about fixing theses latency problem, however,
>> > > understand that the patch you are talking about aren't the right
>> > > way to do.
>> >
>> > So we should not add any functionality that isn't optimally implimented?
>> > Gee, I think that eliminates about 98% of the kernel, and for that matter just
>> > about every OS in existance.
>> >
>>
>> It is implemented the *wrong way* and could cause *big*
>> problem on the long term...
JA> Didn't Linus' comments yesterday contradict that statement. As I read them
JA> he agreed that the copy_to_user and copy_from_user functions should be
JA> fixed and selective (fully explained) pre-emption points added.
Yes, Linus accept THIS pre-emption points.
JA> So the implmentation was right but the problem was the massive sprinkling
JA> of unexplained preemption points was the problem.
JA> Or did I misunderstand his comments?
You misunderstood his comments. Linus basically said "Ok, if there are just
few places where VERY few pre-emption points can radically improve situation
we can tolerate this. But if we need A LOT OF pre-emption points then we
obviusly doing something REAL wrong and thus we need better solution. Why ?
Since if we have few bottlenecks of any sort (this time bottleneck is time
spent in non-preemptive parts of kernel) and number of such bottlenecks is
small (one, two, ten at most) we can hope to find ALL such bottlenecks, fix
them with kludges and hope that it'll fix the whole thing foever (or at least
for long time). If we see that there are tens or hundreds of such bottlenecks
then we obviously playing game without hope to win: if such bottleneck is
really common thing in kernel there are will be new ones in future for sure
and thus maintaining of kernel will become endless loop of searching such
bottlenecks, fix then and fix deadlocks caused by them. Thus we need better
solution or REAL strong reasons to believe that there are no better solution."
Ingo patch adds quite a few pre-emption points and DOES NOT explain why it
help things at all. Ingo himself is not satisfied with patch:
-- cut --
*I* was unhappy with the structure of that patch to begin with. The patch
is ugly and unacceptable (read: a kludge) for inclusion into the
mainstream kernel, period. I also said that i'll send a similar patch for
2.4 as well, once the 2.4 codebase stabilizes. (right now we still have a
high flux of fixes coming in - but i'll soon port the patch to 2.4)
-- cut --
And if author himseld is not satisfied with approach then how on Earth we
can expect Linus to be satisfied ?
P.S. It IS possible that latency issue is important enough for such effort.
But if there are no simple clean solution to problem (and we DO NOT have such
simple clean solution so far) then we need to treat it like SMP threading
issue: peoples should experiment and find good places to add pre-emption
points (as Linus said SMP spinlocks in UP can be used), each one must be
discussed by "kernel wizards" and so on. NOT something you want to do at
2.4.0-testX stage ...
P.P.S. And no "just put Ingo patch for now and think about proper solution
in 2.5" will not go as well. By two reasons:
1. Once kludge is in kernel it's VERY hard to pull it out. Most peoples who
will otherwise try to cook up proper solution in this case will say "Ok, we
have something that barely works and we have other things to play with".
2. Patch touches quite a few intimate kernel points and thus it's not clear
how it'll affect stability of kernel.
Each one is enough to reject it.
-
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:09 EST