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 for Android: free password hash cracker in your pocket

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

Message-ID: <4850D9AC.3040706@aitel.hist.no>
Date:	Thu, 12 Jun 2008 10:09:16 +0200
From:	Helge Hafting <helge.hafting@...el.hist.no>
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

Leon Woestenberg wrote:
[...]
> 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?
>   
That can be done of course, but that too will cause breakage.
Consider a multithreaded app mistakenly relying on sched_yield.

Priority downgrading might work really well as long as this app runs alone,
the yielding thread stops and the others progress, so sched_yield works
for "userspace locking". And it works so well, the app uses it a lot.

Then someone recompiles the distro or runs some other kinds of cpu hogs
that drives the load well above 1. Users expect the apps to run a little
slower because of this. But a load of 5 still ought to give you 1/5
of the cpu - and with today's CPU's that might still be better than
a 5-year old machine. Interactive software should almost not notice,
as it don't use the cpu that much anyway - and it gets priority over
cpu hogs when it occationally needs to do something.

But now this multithreaded app practically
stops because it yields a lot - an everytime it lowers its priority
below not only its own other threads, but below the various
cpu hogs as well. (Compilers gets dynamic boosts too, as they
wait a little for the disk now and then. A parallel compile still
keeps the total load high.)

I remember seeing openoffice taking 5min to start some years ago,
with a compile going on. Of course there were other problems
like swapping and a smaller computer, but other apps were merely slow,
not that glacial.
> On the other hand, I don't think anything should encourage the use of
> sched_yield() outside of the rare SCHED_FIFO/RR case.
>   
Exactly. There seems to be no way to make sched_yield work "as expected"
for all the ways it is abused, so better use something else.

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/