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

On 2026-01-21 05:34, Olivier Certner wrote:
> Hi,
> 
>> 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.
> 
> Results measured how?  When was the last time a comparison was made?
> 
>> Not looking for an argument here.
> 
> Hmm...
Hoowee. That's some passive aggressive stuff, right there. ;)

> 
>> 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.
> 
> Some people in this thread are apparently getting emotional with this topic 
> of
> potentially retiring 4BSD to the point where they cannot even grasp simple
> propositions.  You may have your reasons, I certainly don't dispute that.  
> But at
> least I would like my real message to be understood for what it is and that 
> you
> stop talking past me.
I'm not attempting to "talk past you". Nor do I have an emotional viewpoint 
on this matter.
My perspective is purely pragmatic.
> 
> So I'll try again with another formulation, even if it is redundant as it is
> logically implied by what I've already said.  Please read it carefully:
> I do not intend to retire 4BSD if (we know for sure that) there are 
> workloads
> where it performs significantly better than ULE.
> 
> Does that reassure you?
No...

You have gone to great lengths to indicate that you have put alot of time
and effort into spearheading the task of improving ULE scheduling and that
your findings will dictate it's outcome. Even to the demise of 4BSD:

> Once these problems are fixed, it's likely that, experiments confirming,
> there won't be any more reason to keep 4BSD around.  One of my personal
> goals is to deprecate 4BSD in 16 if possible, as it is more and more
> irrelevant on modern machines and seems too lightly tested.

You clearly have an axe to grind.

IMHO I find it astounding that you're so dismissive toward 4BSDs relevance.
You're quick to dismiss anyone's suggestion to the contrary. With the 
possible
exception of Steve. You have zero knowledge of anyone else's use case for 
choosing
4BSD over ULE. This is not taking an objective view on scheduling. Nor does 
it
make a good case for your "improvements" on ULE.
Make no mistake; I'm *thrilled* that *anyone* is willing to take another look 
at
scheduling and even more so, to actually make the time to do it. But 
scheduling
is the epitome of objectivity and nothing in this thread suggests 
objectivity.

I'd like to suggest that we take a whole other look at this and how we might
*all* make contributions to improve FreeBSDs scheduler or schedulers.
These contributions might only be to present actual use cases, and or the
results of those use cases. A predisposition to nuke 4BSD does not suggest a
well conceived plan for improving the scheduling/schedulers on FreeBSD.
We may well discover that one-true-scheduler is not practical and that having
several is a more realistic choice.

FWIW My corporation is NET centric. I'm the president and CTO. As such, I'm
largely responsible for what gets done. I write a lot of the code. Our 
systems
are largely autonomous. Meaning, nobody's launching DE's or opening a 
browser,
media player,... They perform their assigned tasks. Reacting if/as they're
intended. IOW these systems require almost no human "inter-action". As a 
result,
they don't produce loads "typical" to most experienced by "FreeBSD users". It 
is
for this reason (I assume) that we discovered that 4BSD achieved better 
results
in "flattening" the graph than ULE. This is the reason I chose to defend 
4BSD.
I have no emotional attachment to it. My concerns are pragmatic. I'm 
responsible
for the bottom-line at the corporation and for us, 4BSD makes us more money 
than
ULE. It's as simple as that.

Let's "reboot" this thread. What do you say? :)

> 
>> 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.
> 
> I hope you understand this as an argument for actually testing ULE and 
> especially
> responding to future test calls in the area, as doing so will likely cost 
> you much
> less than keeping 4BSD around by yourself.
> 
> Thanks and regards.

--Chris