On Sat, 1 Jul 2000 22:06:13 +0400 (MSD), "Khimenko Victor"
<khim@sch57.msk.ru> wrote:
>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.
You make a good point.
It looks like the REAL problem is that relatively simple kernel
programming constructs can take a tremendous amount of elapsed time
because of the amount of data or number of control blocks or size of
video screen or whatever. That long elapsed time (100ms, 4000ms or
whatever) causes other processes which can't afford long latencies to
fail. One simple response is to reprogram the logic to be more
efficient and thus quicker. But that is not always possible. X number
of bytes squeezing into the ISA bus takes Y amount of time.
I think this is the more general problem that needs some study.
One system I work with has the concept of processing queues. When a
particular type of work is needed, the process is queued be processed.
For this application, you would take an expected long process and
create an interruptible process queue to manage the work. You would
need to be careful about locks, of course.
john alvord
-
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