Huh? I said that the cache isn't going to cause this sort of problem and
your answer is "cache line aliasing"? If that's your claim, prove it.
Work through the math and show us all how "cache line aliasing" can cause
100% variance in your benchmark but will cause 5% variance in lmbench.
: No, you're misrepresenting what I said. I take the minimum not because
: it looks better, but because it the correct thing to do. The average
: and maximum times can be polluted with other effects (interrupt
: processing). The minimum time is more robust against these effects.
That's funny: the lmbench BENCH() macro does 10 runs and takes the median.
Even when I add about 1K interrupts/second, it still varies less than 10%.
Why does your benchmark vary so much by comparison? Why doesn't lmbench
vary the same amount?
: Note that the true context switch time cannot be greater than the
: minimum time measured.
That's absolutely not true. Consider a bell shaped distribution
of results. You are reporting the minimum. If it were true that the
results consistently followed a bell distribution, your minimum would
be extremely misrepresentitive. That's why lmbench takes the median,
it gets the result that is squarely in the bell; if it turns out that
normal case is near the min, that's fine, that's what the number will be.
Carl and I did an extensive amount of statistical analysis to make sure
that the numbers would stand up.
Taking the minimum is not "the correct thing to do", it just happens to
show more realistic numbers for your flawed benchmark.
: Note that with the fix from Linus, I'm now seeing 0.2 us overhead for
: every extra process on the run queue for a PPro 180, and 0.91 us for a
: Pentium 100. This sounds much closer to what you're measuring.
:
: Again, since the fix means that FPU state isn't saved (my tests don't
: frob the FPU), and hence less cache pollution, I think this indicates
: my tests are valid.
:
: > Given that I've not seen a production workload generate a run queue depth
: > of 24 in the last 10 years, I'm just not convinced that this is a problem.
:
: I'm looking at potential depths of 10. Even there, the effect is still
: noticeable.
So let's look at that. On your Pentium 100, I'll bet your context
switch is something like 8 or 9 usecs. So let's say you have 10
background processes and they jack up your context switch time to 18
usecs instead of 9. In order for you to have a run queue depth of 10,
you are going to need to be pretty heavily CPU bound - if you aren't,
then you are blocking on I/O and your run queue isn't as long as you
are suggesting. So each process is, on average, using its whole time
slice of 10,000 usecs. The net effect of the run queue depth is that you
lose 9 usecs of CPU time every 10,000 usecs. That's a slowdown of .1%
- you're telling us that 1/10th of a percent is noticeable?
And before you start arguing that your processes switch more often than
that, let's say they only run for 1/10th of their time slice - then it
is 1%. And if they aren't running for their whole time slice then they
are getting taken off the run queue and there goes your argument that the
run queue is deep. Remember, the claim all along has been that a long
run queue will cause a problem. If you don't have that long run queue,
we all agree there is no problem. So the issue here is that if you have
the long run queue, the effects are less than 1/10th of a percent.
So where's the problem?
-
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/