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.
The benefits for web browsers seem to have been well covered, so I thought I'd try mariadb out a bit. On the second-crappiest amd64 box I still run (a sun v20z) I get significantly better results with the mysql tests in sysbench using the configuration specified here: https://mariadb.com/kb/en/mariadb/sysbench-benchmark-setup/ On the select_random_points test, for example, with 3 threads (on a 2 cpu box) running for 5 minutes, across 4 different runs: before: read/write requests: 554817 (1849.39 per sec.) read/write requests: 582590 (1941.96 per sec.) read/write requests: 573752 (1912.50 per sec.) read/write requests: 571679 (1905.59 per sec.) after: read/write requests: 661234 (2204.11 per sec.) read/write requests: 647648 (2158.82 per sec.) read/write requests: 649752 (2165.83 per sec.) read/write requests: 642049 (2140.16 per sec.) Not a real database performance test, but it at least shows that it helps things other than browsers.
