On Sat, Mar 12, 2016 at 10:36 AM, Michal Mazurek <akf...@jasminek.net> wrote:
> Gregor Best attempted to improve the scheduler in 2011: > http://comments.gmane.org/gmane.os.openbsd.tech/27059 > Here is another attempt, it takes up where the previous one left off. > > This is also mostly based on the main idea behind Linux CFS or > BFS. I found BFS to be described more clearly: > http://ck.kolivas.org/patches/bfs/4.0/4.3/4.3-sched-bfs-467.patch > > > Some notes: > > Chrome is still not very usable. > > Much more work is needed, e.g. there is some MD code on sparc64 and > alpha that depends on spc_schedticks that needs to be understood and > rewritten. > > Maybe using RB trees to queue what is usually no more than 5 elements > is overkill. > > p_usrpri and p_priority will go away, so userland utilities like 'ps' > will need to be changed. > > I also want to try and see if implementing one shared queue, instead of > keeping one queue per cpu will improve performance even further. Right > now there are some heuristics to determine whether a process should > switch cpus. This doesn't work very well yet, in my tests with the > attached code sometimes one queue was a second behind another. From > what I understand that's the idea behind BFS and the reason why it > doesn't scale to 4096 CPUs. I see that OpenBSD supports 256 CPUs on > sparc64: > ./arch/sparc64/include/cpu.h:#define MAXCPUS 256 > > Hi Michal, One shared queue is bad when # of CPU goes on increasing as it effectively trends towards a global lock. Thanks
