On Fri, May 26, 2017 at 09:57:16PM +0000, Rick Macklem wrote: > I have now found I can get rid of almost all of the degradation by building the > recent kernel with > options SCHED_4BSD > instead of > options SCHED_ULE > > The 1yr old kernel was built with SCHED_ULE, so the degradation is some change > to the kernel since Apr. 12, 2016 that affects SCHED_ULE but not SCHED_4BSD. > > Any ideas? > What is the load on the system? A long time ago [1], I pointed out that ULE performs very poorly if there is an over commit situation. To boil it down to something simple, the MPI master process on a SMP system with N processers would fork N+1 processes where each process is essentially independent and cpu-bound. N-1 of the processes would be pinned to N-1 cpus and run with nearly 100% cpu usage. The N and N+1 processes would be pinned to a single CPU. The master process would then need to wait for the N and N+1 processes to complete before moving on. Note MPI isn't necessary to show the problem. Simply have an over commit situation with cpu intensive processes coudl kill ULE preformance. 4BSD has never exhibited this problem. [1] http://freebsd.1045724.x6.nabble.com/ULE-scheduling-oddity-td3911224.html -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONowReceived on Sat May 27 2017 - 03:02:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC