On 03/23/2016 18:58, Alexandre Ratchov wrote:
On Wed, Mar 23, 2016 at 09:35:50PM +0100, Mark Kettenis wrote:
This doesn't only change the sched_yield() behaviour, but also
modifies how in-kernel yield() calls behave for threaded processes.
That is probably not right.
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.
I used to think that this is a hack, but now i think this is
necessary.
Even if one day we fix the "browsers problem" in the thread
library, I think this diff will remain necessary to handle
processes calling sched_yield() in a loop, i.e. processes that are
spinning.
Complete and utter hack: penalize processes or threads on
#system calls/time period. Syscalls are more expensive than
normal execution because of locking which blocks other
processes. Reset the counter when process transitions from
inactive->active.
I know that some systems have implemented this type of
input to scheduling according to use of intangible resources.
Geoff Steckel
