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

On 2026-01-19 11:18, Steve Kargl wrote:
> 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.
FWIW we use 4BSD exclusively on some 1,200 servers. As it has proven to 
return the best results for our own use case,
as well as our clients use cases. Not looking for an argument here. But we'd 
feel ill served should you decide to pull
it. While I can't speak for our clients, I'd venture a they'd feel the same. 
As our time to delivery will increase should
we be required to create additional local patches to circumvent 4BSD removal. 
Which would be a long term commitment.

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

-- 
There is no such place as the internet