RE: Periodic rant about SCHED_ULE

From: Mark Millard <>
Date: Wed, 22 Mar 2023 16:20:27 UTC
George Mitchell <> wrote on
Date: Tue, 21 Mar 2023 22:52:16 UTC :

> Yes, you've all heard it before, but I've just reverified on FreeBSD
> 13.1-RELEASE-p7 that SCHED_ULE gives terrible performance for "make
> buildworld" in the presence of a totally compute-bound job (misc/dnetc
> from ports) running at nice 20. World builds in:
> 15597 seconds with SCHED_4BSD without dnetc
> 20477 seconds with SCHED_4BSD with dnetc
> 16006 seconds with SCHED_ULE without dnetc
> 50290 seconds with SCHED_ULE with dnetc.
> When I ask why SCHED_ULE is the default scheduler, I have been told more
> than once that there is some circumstance in which it gives superior
> performance. But no one seems to know what circumstance that is. Guess
> what! I propose that SCHED_4BSD be the default scheduler. -- George

You might want to publish instructions that others could follow
to try to repeat your results in a manor know to do so (at least
in proportion to the number of hardware threads they have in
their context and how performant their system happens to be for
the type of activity).

Does dnetc let you know how much progress it has made? If less
time is spent on buildworld per elapsed time, was more time
spent on dentc over the elasped time, getting significantly more
dnetc work done? (So: a tradeoff on which gets the time?)
Did the system end up using the hardware threads for wasted
overhead activity (less useful-progress for both buildworld and
dnetc instead of more useful total work done)? Did the system
end up with more idle time instead of wasted overhead? Lots of
questions could be formed and investigated.

It is not even clear what the load averages were generally
like vs. the number of hardware threads available. How many
hardware threads was dnetc trying to use? For buildworld,
what -jN was in use? How many hardware threads were
provided by the system?

For some systems, buildworld using all the hardware threads
( -jN ) would be I/O bound instead of CPU/RAM-subsystem bound.

Giving folks a way to know they are repeating your tests
appropriately, could give interested folks a way to answer
their own questions.

Mark Millard
marklmi at