Re: SCHED_ULE should not be the default

On Mon, 12 Dec 2011 08:04:37 -0800
mdf_at_FreeBSD.org wrote:

> On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn
> <gljennjohn_at_googlemail.com> wrote:
> > On Mon, 12 Dec 2011 15:13:00 +0000
> > Vincent Hoffman <vince_at_unsane.co.uk> wrote:
> >
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 12/12/2011 13:47, O. Hartmann wrote:
> >> >
> >> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> >> issue. And yes, there are cases where SCHED_ULE shows much better
> >> >> performance then SCHED_4BSD. [...]
> >> >
> >> > Do we have any proof at hand for such cases where SCHED_ULE performs
> >> > much better than SCHED_4BSD? Whenever the subject comes up, it is
> >> > mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> >> > 2. But in the end I see here contradictionary statements. People
> >> > complain about poor performance (especially in scientific environments),
> >> > and other give contra not being the case.
> >> It all a little old now but some if the stuff in
> >> http://people.freebsd.org/~kris/scaling/
> >> covers improvements that were seen.
> >>
> >> http://jeffr-tech.livejournal.com/5705.html
> >> shows a little too, reading though Jeffs blog is worth it as it has some
> >> interesting stuff on SHED_ULE.
> >>
> >> I thought there were some more benchmarks floating round but cant find
> >> any with a quick google.
> >>
> >>
> >> Vince
> >>
> >> >
> >> > Within our department, we developed a highly scalable code for planetary
> >> > science purposes on imagery. It utilizes present GPUs via OpenCL if
> >> > present. Otherwise it grabs as many cores as it can.
> >> > By the end of this year I'll get a new desktop box based on Intels new
> >> > Sandy Bridge-E architecture with plenty of memory. If the colleague who
> >> > developed the code is willing performing some benchmarks on the same
> >> > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> >> > recent Suse. For FreeBSD I intent also to look for performance with both
> >> > different schedulers available.
> >> >
> >
> > These observations are not scientific, but I have a CPU from AMD with
> > 6 cores (AMD Phenom(tm) II X6 1090T Processor).
> >
> > My simple test was ``make buildkernel'' while watching the core usage with
> > gkrellm.
> >
> > With SCHED_4BSD all 6 cores are loaded to 97% during the build phase.
> > I've never seen any value above 97% with gkrellm.
> >
> > With SCHED_ULE I never saw all 6 cores loaded this heavily.  Usually
> > 2 or more cores were at or below 90%.  Not really that significant, but
> > still a noticeable difference in apparent scheduling behavior.  Whether
> > the observed difference is due to some change in data from the kernel to
> > gkrellm is beyond me.
> 
> SCHED_ULE is much sloppier about calculating which thread used a
> timeslice -- unless the timeslice went 100% to a thread, the fraction
> it used may get attributed elsewhere.  So top's reporting of thread
> usage is not a useful metric.  Total buildworld time is, potentially.
> 

I suspect you're right since the buildworld time, a much better test,
was pretty much the same with 4BSD and ULE.

-- 
Gary Jennejohn