Re: Interesting scheduling times - NOT

Larry McVoy (lm@bitmover.com)
Mon, 21 Sep 1998 10:11:14 -0600


Richard Gooch <rgooch@atnf.csiro.au>:
: > >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.
:
: And it's also entirely consistent with cache interactions, I hope
: you'll agree.
[...]
: Also, I get variability even *without* the extra processes, even in
: the minimum times. I can run the test from one window and get
: reasonably consistent differences with another window.
: Now, one difference I can think of between those two windows is that
: one is in a different place in the list of tasks. That implies cache
: effects.

I did the same thing and there are indeed cache effects. In 4 xterms
on one P5@166, I get numbers that vary from 6.1 usecs to 7.2 usecs.

So, yes, there are cache effects. In this case, we are looking at 15%
variance due to cache effects. However, those cache effects are mostly in
the pipe system call, not in the scheduler. If I run the same benchmark
and include the pipe overhead as part of the cost, then the variance
drops to 4.2%.

Since you aren't using pipes, you are using sched_yield() which is a
much more direct path to causing a context switch, your variance should
be similarly low.

Look, if you had a different approach to the problem and you were showing
10% variance where I thought you should get 5%, I don't think anyone would
be really that worried about your results. But when you are getting 100%
variance when you should be getting 5%, yeah, that's a problem. In fact,
that completely invalidates your results. They are just meaningless. And
arguing that it is cache effects, when we can demonstrate that the cache
effects are minimal, doesn't help your case at all.

-
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/