On Sunday 06 July 2003 04:21, Davide Libenzi wrote:
> On Sun, 6 Jul 2003, Daniel Phillips wrote:
> > On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> > > Your last point is most important. At the moment, a SCHED_RR process
> > > with a bug will basically lock up the machine, which is totally
> > > inappropriate for a user app.
> >
> > How does the lockup come about? As defined, a single SCHED_RR process
> > could lock up only its own slice of CPU, as far as I can see.
>
> They're de-queued and re-queue in the active array w/out having dynamic
> priority adjustment (like POSIX states). This means that any task with
> lower priority will starve if the RR task will not release the CPU.
OK, I see, I didn't pay close enough attention to the "it will be put at the
end of the list _for its priority_" part.
So SCHED_RR is broken by design, too bad. Now, how would SCHED_RR_NOTBROKEN
work?
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:26 EST