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] [day] [month] [year] [list]

Message-ID: <485231E6.30101@aitel.hist.no>
Date:	Fri, 13 Jun 2008 10:37:58 +0200
From:	Helge Hafting <helge.hafting@...el.hist.no>
To:	Bodo Eggert <7eggert@....de>
CC:	Leon Woestenberg <leon.woestenberg@...il.com>,
	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

Bodo Eggert wrote:
> On Thu, 12 Jun 2008, Leon Woestenberg wrote:
>   
[...]
>>
>> 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 system as a whole will perform better if the busy-wait is avoided - yes.
A multithreaded app actually using yield this way may suffer badly though.

Consider a case where two threads use yield() for synchronization, and 
there is
some contention. Ideally, the two threads want to ping-pong the cpu between
them. In the precence of other processes, they want to use up their fair 
amount of
cpu in this manner. If they busy-wait, then both the app and the system 
overall gets
slower.

Now, consider what happens if yield() really do lower the priority, or 
does something
like "sleep(1)  unless there really is nothing else to run". 
Busy-waiting will disappear,
and the overall performance will be fine. The app running alone will 
also seem fine.

The app running with some contention - massive use of yield - on a machine
with some other load will almost stop. Every yield will wait for all the 
other
processes on the system, not only the process/thread we needed to wait for.

Ideally, yield() from a non-realtime process should cause a segfault, 
that would
crash all software abusing it, forcing a change. Too drastic though. :-/

>> 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.
>   
And this is the problem - suddenly those niced cpu hogs trumps an
interactive process that seems hopelessly stuck.

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