SCHED_ULE should not be the default

Daniel Kalchev daniel at
Thu Dec 15 07:46:25 UTC 2011

On 15.12.11 01:39, O. Hartmann wrote:
> On 12/14/11 18:54, Tom Evans wrote:
>> On Wed, Dec 14, 2011 at 11:06 AM, George Mitchell
>> <george+freebsd at>  wrote:
>>> Dear Secret Masters of FreeBSD: Can we have a decision on whether to
>>> change back to SCHED_4BSD while SCHED_ULE gets properly fixed?
>> Please do not do this. This thread has shown that ULE performs poorly
>> in very specific scenarios where the server is loaded with NCPU+1 CPU
>> bound processes, and brought forward more complaints about
>> interactivity in X (I've never noticed this, and use a FreeBSD desktop
>> daily).
> I would highly appreciate a decission against SCHED_ULE as the default
> scheduler! SCHED_4BSD is considered a more mature entity and obviously
> it seems that SCHED_ULE needs some refinements to achieve a better level
> of quality.

My logic would be, if SCHED_ULE works better on multi-CPU systems, or if 
SCHED_4BSD works poor on multi-CPU systems, then by all means keep 
SCHED_ULE as default scheduler. We are at the end of 2011 and the number 
of single or dual core CPU systems is decreasing. Most people would just 
try the newest FreeBSD version on their newest hardware and on that base 
make an "informed" decision if it is worth it. If on newer hardware 
SCHED_ULE gives better performance, then again it should be the default.

Then, FreeBSD is used in an extremely wide set fo different 
environments. What scheduler might benefit an one CPU, simple 
architecture X workstation may be damaging for the performance of 
multiple CPU, NUMA based server with a large number of non-interactive 
processes running.

Perhaps an knob should be provided with sufficient documentation for 
those that will not go forward to recompile the kernel (the majority of 
users, I would guess).

I tried switching my RELENG8 desktop from SCHED_ULE to SCHED_4BSD 
yesterday and cannot see any measurable difference in responsiveness. My 
'stress test' is typically an FLASH game, that get's firefox in an 
almost unresponsive state, eats one of the CPU cores -- but no 
difference. Well, FLASH has it's own set of problems on FreeBSD, but 
these are typical "desktop" uses. Running 100% compute intensive 
processes in background is not.


PS: As to why Linux is "better" in these usages: they do not care much 
to do things "right", but rather to achieve performance. In my opinion, 
most of us are with FreeBSD for the "do it right" attitude.

More information about the freebsd-stable mailing list