In article <o1e3s3$fbb$1...@serpens.de>, Michael van Elst <mlel...@serpens.de> wrote: >hub...@feyrer.de (Hubert Feyrer) writes: > >>a) leave the situation as-is and wait for research to get a perfect formula >>b) commit the patch we have and wait for the research to be done > >>Given that the existing patch in PR kern/43561 and PR kern/51615 does >>improve the current situation, I'd vote for option "b". > >While that change is obviously good for the heavy-cpu case, I tried to >test this with other workloads, in particular a system build. There >the build was a few percent slower. > >We should at least benchmark a few other use cases to see wether the >scheduler change isn't a regression. > >I've made a new patch: > >http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/kern_runq.diff > >-> it uses 8 guard bits (multiply by 256 instead of 2). >-> it lets you configure the moving average factor in percent > (default is 50% like now) with a sysctl.
I like that... christos
