On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > Applications using multiple threads often call sched_yield(2) to > indicate that one of the threads cannot make any progress because > it is waiting for a resource held by another one. > > One example of this scenario is the _spinlock() implementation of > our librthread. But if you look on https://codesearch.debian.net > you can find much more use cases, notably MySQL, PostgreSQL, JDK, > libreoffice, etc. > > Now the problem with our current scheduler is that the priority of > a thread decreases when it is the "curproc" of a CPU. So the threads > that don't run and sched_yield(2) end up having a higher priority than > the thread holding the resource. Which means that it's really hard for > such multi-threaded applications to make progress, resulting in a lot of > IPIs numbers. > That'd also explain why if you have a more CPUs, let's say 4 instead > of 2, your application will more likely make some progress and you'll > see less sluttering/freezing. > > So what the diff below does is that it penalizes the threads from > multi-threaded applications such that progress can be made. It is > inspired from the recent scheduler work done by Michal Mazurek on > tech@. > > I experimented with various values for "p_priority" and this one is > the one that generates fewer # IPIs when watching a HD video on firefox. > Because yes, with this diff, now I can. > > I'd like to know if dereferencing ``p_p'' is safe without holding the > KERNEL_LOCK. > > I'm also interested in hearing from more people using multi-threaded > applications.
In the ffmpeg test case, the frames-per-second increased 25%. The only modification in the kernel was your patch. -- Juan Francisco Cantero Hurtado http://juanfra.info
