Messages in this thread | | | Date | Sat, 19 Sep 1998 08:46:50 +1000 | From | Richard Gooch <> | Subject | Re: Interesting scheduling times - NOT |
| |
H. Peter Anvin writes: > Followup to: <199809180835.BAA30897@bitmover.com> > By author: lm@bitmover.com (Larry McVoy) > In newsgroup: linux.dev.kernel > >=20 > > 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. > >=20 > > 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. > >=20 > > Would this work if the processes where SCHED_RR as opposed to normal > dynamic-priority processes?
Nope. If you have two SCHED_FIFO or SCHED_RR (RT) processes sitting in sched_yield() loops then no SCHED_OTHER (ordinary user) process gets *any* time until *both* RT processes block. This is how it should be and looking at the scheduling code you can see this.
My test uses SCHED_FIFO.
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/
| |