> Scene2: with need_resched
> Process A copies one block
> One higher priority interactive process becomes ready and
> we resched. This process rapidly returns to A
> which starts writing again , the second interactive process
> becomes ready and ...
>
> After each switch A wipes the cache, we have an additional
> switch, and total compute time is much longer not to mention
> that we double the number of context switches.
I'm not sure I see your point here. Seems like there are two choices that
are compatible with low dispatch latency:
1) Eliminate all copies.
2) Sometimes wake up a thread during a copy.
It's not like 1 is going to happen, so what's wrong with 2? RTLinux is
also going to wake up to a cold cache much of the time.
Some thoughts:
Newer Alphas have cache hints that can be used to avoid blowing out the
cache during copies. Do any Intel CPUs have this?
Preemption points (though ugly) can be put at places in the code where
there's a shift in cache locality; this will prevent some of the lossage
due to cache dirtying.
How low does dispatch latency actually need to be? I was under the
impression that small millisecond latency is good enough for an awful lot
of applications. If we made a histogram by putting RTLinux and
lowlatency-Linux applications into bins based on the worst dispatch
latency they could reasonably tolerate, what would it look like?
John
-
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 Mar 31 2000 - 21:00:25 EST