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: <Pine.LNX.4.58.0806130006530.8419@be10.lrz>
Date:	Fri, 13 Jun 2008 00:33:26 +0200 (CEST)
From:	Bodo Eggert <7eggert@....de>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
cc:	7eggert@....de, 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

On Thu, 12 Jun 2008, Leon Woestenberg wrote:
> 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 code after yield() is most likely to not run successfully (and as a
result will return to the yield call) unless some time passes, and this
time can pass while another process gets the CPU. It might even depend on
another process to change the system state.

Besides that, "Schedule another process, if you can" is part of the 
semantics of yield. The code after yield should therefore be expected to 
NOT be the very next code to run.

If you can't do that, it's fine, the process will abuse some more innocent 
electrons for busy waiting, but if you can support this yield() semantics, 
the system will perform much better. Won't it?

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

I expect it to be. It may cause lower-nice-level processes to run,
but the (lack of) definition allows it.

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

I agree that sleeping should be prefered, but if you really have to 
busy-wait for the next thread, you'll want yield() semantics.
--
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/