Re: SCHED_RR is broken + patch

Dimitris Michailidis (dimitris@cthulhu.engr.sgi.com)
Wed, 26 Apr 2000 14:47:18 -0700 (PDT)

On 26-Apr-2000 Artur Skawina wrote:
> Dimitris Michailidis wrote:
>>
>> Borislav Deianov <borislav@lix.polytechnique.fr> writes:
>>
>> > sched_yield doesn't always yield for SCHED_OTHER threads
>>
>> Processes should yield only to higher or equal priority processes. A
>> SCHED_OTHER thread executing sched_yield doesn't have to yield just
>> because
>> there may be other SCHED_OTHER processes available.
>
> depends on the priority model chosen. (ie if all SCHED_OTHER threads
> run with equal static priority then having a sched_yield() that defers
> to any SCHED_OTHER thread eligible to run makes sense)

Agreed. One problem with treating all SCHED_OTHER processes as equal is
that we'll have to convince __schedule_tail() not to immediately preempt a
chosen SCHED_OTHER process if it is low priority according to goodness().

>> > counter for SCHED_FIFO threads is never reset
>>
>> It should not expire in the first place. SCHED_FIFO processes do not
>> have slices.
>
> it's not about expiring; it's about entering the scheduler on
> every clock tick, because of the way the counter is handled.

And that, in turn, is because the counter for SCHED_FIFO processes is
allowed to reach 0 and then it stays there causing a trip to the scheduler
at every tick. Ideally, counter should be ingored for SCHED_FIFO, but that
would require special case code in the timer interrupt. In my scheduler
patch I set SCHED_FIFO counters to LONG_MAX, which effectively gives them an
infinite slice.

-- 
Dimitris Michailidis                    dimitris@engr.sgi.com


-
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/