Re: Interesting scheduling times - NOT

Richard Gooch (rgooch@atnf.csiro.au)
Sat, 19 Sep 1998 08:46:50 +1000


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/