On Sat, Mar 12, 2016 at 08:35:31PM +0100, Juan Francisco Cantero Hurtado wrote: > On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek 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. > > Chrome is not the best benchmark for the scheduler ATM. > > Until the work in malloc to enhance the support for multithreaded > programs is finished, forget Chrome and Firefox. > > > > > 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 > > > > Nice is not yet supported, but it's easy to add (uncomment and modify > > 'offset' in sched_deadline(). I didn't want to add it yet to test just > > how fair this method is. Currently all processes are equal. > > > > Other operating systems provide a couple of different schedulers to > > choose from, this diff overwrites the 4bsd scheduler with the new code > > and leaves no choice. > > > > With the new code I got some visible improvements when compiling the > > kernel: > > old: 1m46.74s real 5m08.48s user 1m27.37s system > > old: 1m46.61s real 5m06.93s user 1m28.13s system > > old: 1m49.91s real 5m19.71s user 1m28.25s system > > new: 1m38.05s real 5m12.16s user 0m55.86s system > > new: 1m38.70s real 5m12.36s user 0m57.82s system > > new: 1m39.10s real 5m16.06s user 0m56.91s system > > That is going to make happy to people running bulk builds :) > > > > > I would be interested in hearing if the new code broke something for > > anyone. > > > > Is there a chance for a scheduler rewrite like this to be commited?
>From time to time, I run a batch video conversion. I tried the same commands with and without your patch. Your patch is slowing down the frames-per-second about 30%. Here are the commands: $ download some 20-30 minutes videos in mp4 format (youtube is fine for this) $ install the packages ffmpeg and libx264 $ mkdir output $ for i in *.mp4; do ffmpeg -y -i "$i" -vf 'scale=320:-1' -map 0:v:0 -map 0:a:0 -sws_flags spline -map_metadata -1 -c:v libx264 -profile:v baseline -b:v 360k -c:a aac -strict -2 -ar 44100 -ac 2 -b:a 128k -movflags faststart "output/$i"; done -- Juan Francisco Cantero Hurtado http://juanfra.info
