Re: Periodic rant about SCHED_ULE

From: Mark Millard <>
Date: Wed, 22 Mar 2023 20:34:17 UTC
On Mar 22, 2023, at 12:40, George Mitchell <> wrote:

> On 3/22/23 15:21, Mark Millard wrote:
>> George Mitchell <> wrote on
>> Date: Wed, 22 Mar 2023 17:36:39 UTC :
>> [...]
>>> Here are the very complicated instructions for reproducing the problem:
>>> 1. Install and start misc/dnetc from ports.
>> Installing is likely easy, as likely would be building
>> with default options (if any). I know nothing about
>> starting misc/dnetc so that is research. (Possibly
>> trivial, although if it has alternatives to control
>> then I'd need to match that context too.)
> service dnetc start

I built and installed misc/dnetc and got a binary
blob that clearly was not built in my environment:

# file /usr/local/
/usr/local/ ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 10.1 (1001515), FreeBSD-style, stripped

Way older FreeBSD vintage than the locally available toolchains
would normally build. Some might be cautious about such a thing.

The man page reported that:

     If you have never run the client before, it will initiate the menu-driven
     configuration. Save and quit when done, the configuration file will be
     saved in the same directory as the client. Now, simply restart the
     client. From that point on it will use the saved configuration.

I've not seen what the configuration asks about yet.

>>> 2. Run "make buildworld".
>> So on the 32 hardware-thread (16 cores) amd64 machine that
>> I have access to, the test is to only have buildworld use
>> about one hardware thread, no matter what else is going on.
>> I never would have guessed that the steps would not involve
>> more like -j$(sysctl -n hw.ncpu) (so around -j32 in this
>> context). So it is good that you provided your note or
>> I'd not know if I'd done similarly or not when trying such.
>> [Note: -j1 and lack of -j are not strictly equivalent in
>> how make operates. As I remember, the distinction makes
>> a notable difference in the number of subprocesses created
>> directly by make (one per action "line" vs. one for the
>> whole block?). So even using -j1 might make a difference
>> vs. what you specified. I'd have to test to see.]
> I am literally running "make buildworld" with no additional options.

So required for repeating your results, but likely making
such results not be interesting relative to how I normally
deal with buildworld buildkernel and the likel, no matter
if there is other activity in an overlapping time frame or
not: my time preferences are too strong to wait for a single
hardware thread to do my normal builds, even with no
competing activity on the builder.

>>> Standard out conveniently reports how long it took (wall clock).
>> But nothing in your instructions indicate about how
>> to get an idea much progress dnetc made during the
>> various tests? [...]
> Honestly, I've never worried about this part.  But dnetc logs its
> progress in /usr/local/, though not in terms
> that are easy to relate to real-world progress.  Oddly, when I run
> "make buildworld," I'm primarily interested in getting the world built.
> Perhaps others feel differently.

Off topic for the specifics of the actual benchmark
that you run:

Then why not use of -jN ? In my context, any buildworld
using -j1 or no -j at all takes a huge amount of time
longer than letting it use all the hardware threads (or
so). (I've avoided having any I/O bound contexts for
such.) It does not take additional load on the system
for that to be true --including on the 4-core small arm
boards when I happen to buildworld on such (rare).

>> [...]
>> FYI: I've never built with and run the alternate
>> scheduler so if there is any appropriate background
>> for that that would not be obvious on finding basic
>> instructions, it would be appropriate to provide
>> such notes.
>> [...]
> You have to build a new kernel, using a config file in which you have
> replaced "options SCHED_ULE" with "options SCHED_4BSD".     -- George

Thanks for the notes.

I've not decided if I'll do anything with the binary
blob or not.

Mark Millard
marklmi at