Borislav Deianov wrote:
>
> On Wed, Apr 26, 2000 at 05:07:52AM -0700, George Anzinger wrote:
> > Borislav Deianov wrote:
> > >
> > > SCHED_RR threads don't work
> > > sched_yield doesn't work for RT threads
> > > sched_yield doesn't always yield for SCHED_OTHER threads
> > > wrong wake up order for RT threads
> > > sched_rr_get_interval returns constant bogus value
> > > counter for SCHED_FIFO threads is never reset
> > > several wrong and misleading comments in the code
> >
> > Have a look at this patch for the 2.2.14 sched.c. It fixes the first 4
> > of the above items and also fixes the "misses 'need_resched' if set
>
> It doesn't seem to touch the wake up order for RT threads
> (wake_up_process adds the new process to the beginning of the
> runqueue, this is wrong for RT threads). Otherwise it looks OK,
> although I'm not very familiar with the 2.2.14 scheduler so I can't
> really say.
>
> I believe this approach has a fundamental problem, though. The current
> scheduler makes prev default (if still running) before it considers
> all other processes in the main loop. With this patch prev is
> considered when it's encountered in the main loop. I had a patch that
> did the same thing but have since decided that this is wrong for
> SCHED_FIFO threads. Quote from sched_setscheduler(2):
>
> | A call to sched_setscheduler or sched_setparam will put the
> | SCHED_FIFO process identified by pid at the end of the list if it
> | was runnable. ... A SCHED_FIFO process runs until either it is
> | blocked by an I/O request, it is preempted by a higher priority
> | process, or it calls sched_yield.
>
> This means that a SCHED_FIFO process can be forced to the end of the
> list for its priority while still running. Even so, it should continue
> to run and not be preempted by another process with the same
> priority. With your patch it would be preempted at the next
> reschedule.
>
Interesting. On the other hand the code for sched_setschedule() puts
the task at the front of its list. Something else to add to the list of
bugs!
My patch does have an interesting flaw, however. If the only non-idle
task in the run list is the one yielding, the patch will go into a loop
resetting the counters until some other task enters the list (which can
happen as the interrupts are turned on for part of the loop). Not what
one wants from yield. The fix, of course, is to detect the second
counter reset and just making next=prev at that point.
George
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:12 EST