Make sure that a thread that calls sched_yield(2) ends up on the run queue

behind all other threads in the process by temporarily lowering its priority.
This isn't optimal but it is the easiest way to guarantee that we make
progress when we're waiting on an other thread to release a lock.  This
results in significant improvements for processes that suffer from lock
contention, most notably firefox.  Unfortunately this means that sched_yield(2)
needs to grab the kernel lock again.

All the hard work was done by mpi@, based on observations of the behaviour
of the BFS scheduler diff by Michal Mazurek.

ok deraadt@

0 files changed, 0 insertions, 0 deletions