Re: Periodic rant about SCHED_ULE
- Reply: Mark Millard : "Re: Periodic rant about SCHED_ULE"
- In reply to: Mark Millard : "Re: Periodic rant about SCHED_ULE"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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 > >