Re: sched_yield() on 2.6.25

[Leon Woestenberg]

Hello,

On Wed, Jun 11, 2008 at 5:28 PM, Bodo Eggert <7eggert@xxxxxx> wrote:
> Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
>> On Mon, 2008-06-09 at 08:37 +0200, Jakub Jozwicki wrote:
>
>>> From the man sched_yield:
>>>
>>> A  process  can  relinquish  the  processor  voluntarily without blocking by
>>> calling sched_yield().  The process will then be moved to the  end  of  the
>>> queue  for  its static priority and a new process gets to run.
>>>
>>> and also IEEE/Open Group:
>>> http://www.opengroup.org/onlinepubs/000095399/functions/sched_yield.html
>>
>> Yeah, except that is for Real-Time scheduling classes, SCHED_OTHER
>> doesn't have static priority queues.
>>
>> SCHED_OTHER doesn't have a specified implementation - so relying on it
>> to do anything specific is well outside the scope of definition.
>
> OTOH, it's sane not to schedule exactly the thread which just tried
> to say "I can't do any sane work, please run another thread.
>
That's not the definition of sched_yield(). See the earlier emails,
and the quote above.

As the code after sched_yield() has to be executed the thread will be
rescheduled soon (or even immediately) anyway.

The users not understanding the limited scope where sched_yield()
behaves deterministicly, seem to think that _yield() will yield() AND
lower the thread's dynamic priority for SCHED_OTHER. Is downgrading
the dynamic priority a behavioral option?

On the other hand, I don't think anything should encourage the use of
sched_yield() outside of the rare SCHED_FIFO/RR case.

Regards,
-- 
Leon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/