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

20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to