Re: Periodic rant about SCHED_ULE

From: Warner Losh <imp_at_bsdimp.com>
Date: Thu, 23 Mar 2023 20:53:25 UTC
On Thu, Mar 23, 2023, 9:46 PM Mark Millard <marklmi@yahoo.com> wrote:

> Warner Losh <imp_at_bsdimp.com> wrote on
> Date: Wed, 22 Mar 2023 22:57:08 UTC :
>
> > On Wed, Mar 22, 2023 at 1:41 PM George Mitchell <george+freebsd@m5p.com>
> > wrote:
> >
> > > service dnetc start
> > > I am literally running "make buildworld" with no additional options.
> > >
> > >
> > So what are the results for make buildworld -j $(sysctl -n hw.ncpu )?
>
>
> Note: My experiments have been in this -j $(sysctl -n hw.ncpu )
> realm.
>
> > ULE scales much better, but when there's too little to do it can make
> poor
> > choices.
> >
> > ULE is better locked and don't fall over on high core count systems like
> > BSD does at moderate load.
>
> (I'm presuming the above is not about the specifics
> of the effectively different interpretations of the
> likes of having extra "nice 20" activity by the two
> schedulers for the examples related to the original
> "rant", other than the -jN issue.)
>
> Any idea on what scale "high core count systems" need to be
> for what sort of "moderate load" to end up with signficant
> differences?


Sched_bsd is basically unusable on my 64 core 128 thread machine with make
-j 150 (nice or no). With ULE I don't notice. That's not to say ule can't
be better (me not noticing is hardly scientific), but I tried sched bsd
when I got the thread ripper and found the machine too unresponsive when I
was doing large builds...

But I wasn't playing video on this box... so maybe I hit a local optimal
point...

Warner

What sort of context(s) show ULE scaling much
> better? On the 16 core ThreadRipper 1950X (32 hardware
> threads) I've really only demonstrated the "nice 20"
> distinction as significant between the schedulers so far.
> (I do not have acccess to anything with more hardware threads.)
>
> Note: I've not (yet?) been looking at having just a little
> more than the number of hardware threads active (no nice
> involvement).
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>