Umm, what do you use to make sure that all processes start at the same
time? Ie, what's your "start" criterium?
It's entirely possible that a large portion of your run is done only
with a part of the processes running... As such, your "minimum" values
in particular are especially suspect, because they may be "minima" with
no scheduling happening at all, or scheduling between just a few of the
runs.
>Another pair of successive runs, this time with 12 extra low-priority
>processes, I got 35.2 us and 51.0 us. Pentium 100 (this is an old
>Intel Neptune board).
>
>I've now modified my test code to compute minimum and maximum
>latencies (no extra processes):
>Minimum scheduling latency: 6.2 us
>Average scheduling latency: 15.0 us
>Maximum scheduling latency: 40.5 us
> and on the very next run:
>Minimum scheduling latency: 6.2 us
>Average scheduling latency: 8.6 us
>Maximum scheduling latency: 38.0 us
> and a few runs later:
>Minimum scheduling latency: 7.7 us
>Average scheduling latency: 11.8 us
>Maximum scheduling latency: 145.9 us
>
>Looking at the first pair of results, we can see that the minimum
>scheduling time is relatively stable and the maximum isn't too bad
>either. But the average does indeed change a lot.
Which is entirely consistent with the idea that you have a "random"
amount of processes during the first and last few thousand iterations.
This is why using a "packet" based approach is so stable, and why using
"sched_yield()" is so unstable. "lmbench" makes _sure_ that it always
gets exactly the expected re-scheduling behaviour by passing along a
packet in a pair of pipes. You have no such synchronization as far as I
can tell.
> This must mean that
>the distribution of scheduling times has changed from run to run, and
>I suspect memory subsystem/cache interactions.
There could certainly be cache effects, but if I were you I'd look very
very closely at synchronization issues in your program.
This could easily explain why you get different results the first time
you run the program: you get page-faults in one or more of the threads,
so part of the yield() loop won't result in any schedule at all simply
because there is only one process runnable, for example.
You even have a "usleep()" somewhere in your benchmark, and it's fairly
unrealistic to expect the different yield loops to be synchronized to
each other..
Linus
-
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/