Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: 2.5.74-mm1 | Date | Sun, 6 Jul 2003 15:54:48 +0200 |
| |
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/
| |