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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:11 EST