linux-kernel - Re: sched

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]

Date:	Mon, 20 Oct 2008 17:02:08 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	david@...g.hm
CC:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: sched_yield() options

david@...g.hm wrote:
> I've seen a lot of discussion about how sched_yield is abused by 
> applications. I'm working with a developer on one application that looks 
> like it's falling into this same trap (mutexes between threads and using 
> sched_yield (or more precisely pthread_yield()) to let other threads get 
> the lock)
> 
> however I've been having a hard time tracking down the appropriate 
> discussions to forward on to the developer (both for why what he's doing 
> is bad, and for what he should be doing instead)
> 
> could someone point out appropriate mailing list threads, or other 
> documentation for this?

The main reason why it's bad is that the behaviour of yield() for 
SCHED_OTHER tasks is not strongly defined in the spec.  Depending on 
OS/version you may yield to all other SCHED_OTHER tasks, only one task, 
or anywhere in between.

Also, yield() gives the kernel no information on why it's yielding and 
to whom, so it is impossible for the kernel to make the optimal decision 
in all cases.

For more information, try searching the linux.kernel google groups 
archive.  There's a thread called "yield API" with some information. 
See also " CFS: some bad numbers with Java/database threading [FIXED]".

Chris
--
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/