Larry, you're starting to sound condescending. That's not helpful.
I know what I'm measuring. If you look more closely at the test code
and the scheduler itself, you'll see that my testcode will put the two
main yielding processes into the SCHED_FIFO scheduling class. This
means that they should get total preference over SCHED_OTHER processes
(the low priority processes). And this is indeed what happens when the
test is run: for the duration of the test, every other process on the
system is locked out. The top programme won't even run.
Note that the test code must be run as root (that's why I've put a
warning message in the code). Naturally, in all my tests I run it as
root.
The two yielding processes yield *only* to each other. For them to
yield to SCHED_OTHER processes would mean the scheduler is broken.
> 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.
Top doesn't get a look-in. You must have run this as an ordinary
user.
> 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.
Again, Larry, you're being condescending. I've spent much more than a
millisecond thinking about this, and I do have a good grasp of the
fundamentals of scheduling, RT programming and more. If you don't
agree with my analysis or methodology, that's fine. It's not useful or
necessary to make out that I haven't thought about it properly.
To answer your question, I'll give you another question: just what do
you think is the breakdown of costs in scheduling?
Another way to answer this is to point out that basic scheduling costs
are of the order of microseconds. Is it then unreasonable to have
another few microseconds if the run queue has a handful more entries?
> 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.
Not having see your code, I can't comment on what you're actually
measuring.
Regards,
Richard....
-
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/