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

On Wed, 21 Jan 2026 at 08:28, Steve Kargl <kargls@comcast.net> wrote:
>
> On 1/21/26 05:34, Olivier Certner wrote:
> >
> > 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 don't see emotional responses.  I see responses expressing
> disappointment with a plan to remove 4BSD.
>
> >
> > 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?
>
> Why does 4BSD have to be**significantly better** than
> ULE?  What if 4BSD performs on-par with ULE?
>
> >
> >> 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.
> >
>
> In another response, you noted that you're concentrating
> on testing ULE. That's fine.  But, you also wrote "I did
> not do that for 4BSD, just basic smoke tests and that's
> all."  Again, that's fine.  There is only so much time in
> a day.  But, to draw the conclusion that ULE is better
> than 4BSD, and therefore 4BSD should be removed in FreeBSD
> 16 seems a bit suspect.


Honestly I'd prefer to keep 4BSD as an example scheduler and just make
sure it uses all the scheduler APIs,
is well documented and can be included as a module.

(I had to use it for packet pushing on MIPS network devices back in
2010 -> 2017 timeframe because ULE
was constantly interfering with said packet pushing and preempting
what little cache hotness I may have
had during said packet pushing.)



-adrian