Re: Current ULE state and plans (was Re: HMP scheduling on FreeBSD)

On Mon, Jan 19, 2026 at 12:52 PM Olivier Certner <olce@freebsd.org> wrote:
>
> > Why remove functioning code that people actually use?
>
> How can you be sure it is functioning correctly?  Have you reviewed it?  Has it been tested on a variety of workloads?  What does guarantee it will not break, more or less badly, when some code surrounding it is changed, even when these changes are done carefully?
>
> And who is using it, exactly? You count for 1. Given the past threads on the topic, I expect a few more, but can we even reach 10 or 20, I wouldn't bet on it.
You need to ask "Do you run FreeBSD in an HPC cluster and,
if the answer is yes, which scheduler do you use?".
(I'll admit that I doubt you'll get many responses because almost
 all HPC clusters will be using Linux and not FreeBSD, but maybe
 there are a few?)

>
> Code is not free.  As I've just said, the majority of the burden when maintaining schedulers is testing with different scenarios, possibly also working on tools to automate what we can, which however currently seem far from being able to model the whole reality.  Who is going to perform that?  Are we going to continue to ship under-tested code, creating among users a false sense of real support?

And do you claim FreeBSD is doing the above now for ULE?

To be honest, the NFS code in FreeBSD is "free" (at least in
the sense that no one spends any $$$ on it) and is undertested.
(Personally, I would never claim it is supported. Want software
that is supported, then pay someone or some company $$$ to
support it. Imho, testing/support occurs when companies like
Netflix invest in those resources and FreeBSD benefits as a
side effect. However, for large parts of FreeBSD, there is no
one paying $$$ to test/support it.)
--> I honestly believe most of the code in FreeBSD qualifies
      as under-tested.

Long ago when I did run FreeBSD NFS server code in a
production (or near-production) environment, I always
found 4BSD worked better that ULE and always used it
for those production kernels.
But that was a long time ago, rick

>
> And finally, again, what would be the point of keeping 4BSD around if we reach a state where it has no advantages at all?
>
> > Of course! I was one of the original testers of ULE when Jeff
> > first committed it to the tree.  I suppose I can dig out my
> > email archive to see if I still have our exchanges.
>
> That may be useful.  If possible, I'd like to read them.
>
> > It simply works. <-- There's your feedback.
>
> That's only *your* feedback.  One data point on one workload.  I can imagine that this one matters to you the most, but the world is... bigger.
>
> > ULE is/was a poor choice for a HPC cluster.  But, as I stated, I have
> > not benchmarked ULE vs 4BSD in over a decade.  I gave up, and went
> > with the path of least resistance where all of my custom kernels use
> > 4BSD.
>
> So, claiming that ULE isn't a good choice on HPC now is perhaps an overstatement, don't you think?
>
> Don't get me wrong, I'm not asking you to test it again now.  But I'll ask so after the fixes are pushed.
>
> >   Here's an example of the issue I reported long ago:
> >
> > https://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html
>
> That's very interesting, and shows typical symptoms of problem number 2.  But of course we cannot say for sure, only real testing will tell.
>
> > That's at most a cosmetic bug.  For people using FreeBSD in
> > an HPC environment, the important metric is wall-clock time.
>
> That was just an example.  Off the top of my head, I saw some others, but don't recall them now.
>
> > I'll see if can do testing, but that can be problematic
> > as I try to keep world and ports in sync, and lately
> > ports has been a challenge.
>
> If you have enough time and motivation, you can test now, but what is really important is that you test after the fixes.
>
> Thanks and regards.
>
> --
> Olivier Certner