SCHED_ULE should not be the default

Gary Jennejohn gljennjohn at googlemail.com
Mon Dec 12 16:47:37 UTC 2011


On Mon, 12 Dec 2011 17:10:46 +0100
Lars Engels <lars.engels at 0x20.net> wrote:

> Did you use -jX to build the world?
> 

I'm top posting since Lars did.

It was buildkernel, not buildworld.

Yes, -j6.

> _____________________________________________
> Von: Gary Jennejohn <gljennjohn at googlemail.com>
> Versendet am: Mon Dec 12 16:32:21 MEZ 2011
> An: Vincent Hoffman <vince at unsane.co.uk>
> CC: "O. Hartmann" <ohartman at mail.zedat.fu-berlin.de>, Current FreeBSD <freebsd-current at freebsd.org>, freebsd-stable at freebsd.org, freebsd-performance at freebsd.org
> Betreff: Re: SCHED_ULE should not be the default
> 
> 
> 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.
> 
> -- 
> Gary Jennejohn
> _____________________________________________
> 
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> 


-- 
Gary Jennejohn


More information about the freebsd-performance mailing list