Messages in this thread | | | Subject | Re: Interesting scheduling times - NOT | From | (Larry McVoy) | Date | Fri, 18 Sep 1998 01:35:05 -0600 |
| |
: To give you an example of what a dozen more processes on the run queue : costs you, I ran my test on a Pentium 100. Without the extra processes : I get about 12 us per context switch. With the extra 12 processes I : get about 40 us per context switch. So that single run queue is going : to hurt.
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/
| |