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

On 1/19/26 09:53, Olivier Certner wrote:
>> Please, do not deprecate 4BSD.
> 
> 4BSD will be deprecated provided we can fix ULE's mentioned problems as expected, since, AFAIK, they are the only cases where 4BSD can fare better.
>

Why remove functioning code that people actually use?

>> Although it's been
>> a long time since I benchmarked 4BSD vs ULE with my
>> OpenMPI-based code, 4BSD handled the work load much
>> better than ULE.  Yes, I made Jeff aware of the
>> situation.
> 
> Did this notification produce any useful discussion, and even an analysis?

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.
>> It's unclear how you conclude that 4BSD is lightly
>> tested.  Maybe 4BSD simply works and there's nothing
>> to report.
> 
> Simple:
> - 4BSD has not been the default scheduler since more than 18 years, and the choice of scheduler must be done at kernel compilation time.  That has reduced its exposure to those people that will install custom kernels with it explicitly re-enabled.  I'm willing to bet this is a very small cohort.  Feedbacks would of course be better.

It simply works. <-- There's your feedback.

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.  Here's an example of the issue I reported long ago:

https://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html

> - During that course, some 4BSD bugs have persisted for years (such as incorrect %CPU reporting) and, AFAIK, almost nobody complained.

That's at most a cosmetic bug.  For people using FreeBSD in
an HPC environment, the important metric is wall-clock time.

> Going forward, I'll send a call for testing once the mentioned problems are fixed.  Then, re-testing your scenario would be helpful and the most constructive move.  There's no point in keeping 4BSD if there's not a single scenario where it is clearly better.
> 
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.

-- 
steve