That's right - it's measuring context switches. You are attempting
to measure context switches with a lot of processes on the run queue,
in other words, you have two variables and I have one.
As to taking processes on and off the run queue, yup, that's by design.
In my experience that is part of a context switch cost. Linus said this
a different way, but I'll try it like this: in the cases where I might
be context switching without removing myself from the run queue (i.e.,
my time slice ran out), I just ran for 10,000 usecs. Whether the context
switch is 10 or 100 usecs is in the noise. In the case where I ran less
than my time slice, I am removing myself from the run queue because I'm
blocking on I/O. In that case I may very well have run for an extremely
short time and then context switched, where the context switch does indeed
include a run queue removal. And that's exactly what I wanted to measure,
I never intended to factor that out and you shouldn't want to either.
As to the realistic nature of the benchmark, I must disagre with your
claim. You are claiming that systems have long run queues without
actually showing that to be true, even in your case. At least everything
you've stated so far is conjecture, not based on observation. In other
systems, which sound quite similar to what you have described, I've
seen similar claims of long run queues, but when I went and actually
measured things, it was very rare to see a queue depth of more than 2/CPU.
-
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/