On Wed, Mar 23, 2016 at 06:18:59PM -0400, Ted Unangst wrote: > Mark Kettenis wrote: > > So here is a diff that keeps yield() the same and adds the code in the > > sched_yield(2) implementation instead. It also changes the logic that > > picks the priority to walk the complete threads listand pick the > > highest priotity of all the threads. That should be enough to make > > sure the calling thread is scheduled behind all other threads from the > > same process. That does require us to grab the kernel lock though. > > So this removes NOLOCK from sched_yield(2). I don't think that is a > > big issue. > > this does sound a little better. in theory we should be gifting priority to > the thread with the lock, but if we don't know who... more of this lock > business needs to go kernel side i suspect. still, maybe we can do the > opposite > and raise other threads to this thread's priority?
AFAICS, raised priority is for interactive (aka io-bound) threads. Processes spinning (here by calling sched_yield()) desserve lower priority, as do any cpu-bound thread.
