SCHED_ULE should not be the default
daniel at digsys.bg
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 m5p.com> 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
> 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
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