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

On 1/19/26 12:51, Olivier Certner 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?

Not a kernel expert, so no, I have not reviewed the code.
It has worked for 30 years, so one might conclude it works
for some definition of "work".

If surrounding code is changed (and that code might have
a negative effect on 4BSD), would it not fall on an individual
making the change to do his/her due diligence to ensure that
it does not break surrounding code?

> 
> 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.

I don't know who else may use 4BSD.  Perhaps, they are silent
because they do not wish to engage in discourse that appears
to lead to nowhere.  Perhaps, others that use 4BSD do not
read the freebsd-hacker@ list, so they miss a lonngggg email
that at the very end mentions deprecation of 4BSD.
> 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 finally, again, what would be the point of keeping 4BSD around if we reach a state where it has no advantages at all?

The last time I tested ULE vs 4BSD, it was not on par with
4BSD under HPC workloads.  May be this

   commit e745d729be60a47b49eb19c02a6864a747fb2744
   Author: Alexander Motin <mav@FreeBSD.org>
   Date:   Tue Sep 21 18:14:22 2021 -0400

     sched_ule(4): Improve long-term load balancer.

fixed the issue.
>> 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.

I'll see what I can find.

>> 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?

Again, I stopped testing ULE vs 4BSD years ago.  As
you noted "Code is not free.", well neither is time
and I had other work obligations.

-- 
steve