linux-kernel - Re: sched_yield() on 2.6.25

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c384c5ea0806111545g6e6128bek519ce6022a301339@mail.gmail.com>
Date:	Thu, 12 Jun 2008 00:45:13 +0200
From:	"Leon Woestenberg" <leon.woestenberg@...il.com>
To:	7eggert@....de
Cc:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Jakub Jozwicki" <jozwicki@...er.pl>, linux-kernel@...r.kernel.org,
	"Robert Hancock" <hancockr@...w.ca>
Subject: Re: sched_yield() on 2.6.25

Hello,

On Wed, Jun 11, 2008 at 5:28 PM, Bodo Eggert <7eggert@....de> wrote:
> Peter Zijlstra <a.p.zijlstra@...llo.nl> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/