* Con Kolivas <[email protected]> wrote:
> Not entirely what some would expect. Very little difference under low
> loads, but the maximum latencies exhibited are about the same at
> 300us. However they hare under different workloads. With these
> worklods, on this hardware, running these real time simulations there
> is not a convincing argument for CONFIG-PREEMPT. Note that running
> interbench with the non-real time benchmarks also does not show a
> convincing reason for preempt.
while i do like the PREEMPT_RT results, i think we need to do two more
things to have total confidence in the numbers:
- i think we'll need to increase the number of sample points, by both
increasing the frequency of samples, and by lengthening the
test-time - even if just for a single testrun. Some of the worst-case
latencies i care about in PREEMPT_RT trigger only once every couple
of million interrupts (!). For human interactivity we probably dont
care that much though.
- many of the worst-case latencies relate to some sort of extreme
situation within a particular algorithm. E.g. lots of tasks being
around. Do this for example:
hackbench 50
and Ctrl-Z it after a couple of seconds. You'll see a 1msec (or
larger) blip.
or, fill up swapspace, so that the swap allocation map gets filled
up.
- networking is another frequent source of latencies - it might make
sense to add a workload doing lots of socket IO. (localhost might be
enough, but not for everything)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |