No it doesn't. Your test is broken, it doesn't measure what you think
it measures. Your test depends on the schedulor doing the right thing
(in your mind) when all you are doing is sched_yield(). You had a high
priority process and a bucnh of low priority processes, all yielding to
each other. My guess is that you thought the scheduler would resched
the one high priority process back to itself. Under 2.0.33, at least,
that doesn't happen. I think a lot of operating systems would take the
yielding process out of the resched equation - as does Linux - so what
you are doing is yielding to one of your low priority processes.
This is trivial to see if you just run top while running your test, you
can see the low priority processes getting cycles and they shouldn't be.
I also had doubts that a runq of 12 deep would triple the context switch
time - if you think about it for a millisecond, you would realize that a
context switch is a lot more work than just scanning the runq. How is
it that scanning the runq could dwarf the cost of a context switch?
Answer: it doesn't.
Just to verify my sanity (do it once a day, whether you need it or not :-),
I took the lmbench context switch test and ran it with and without
background jobs. The background jobs were doing
nice(10);
for (;;) getppid();
With 8 processes context switching and 12 background jobs, the time
goes from 11 usecs to 13. Much more sane. This is on a 166Mhz pentium,
no MMX, Linux 2.0.33.
-
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/