Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Dec 2011 16:32:21 +0100
From:      Gary Jennejohn <gljennjohn@googlemail.com>
To:        Vincent Hoffman <vince@unsane.co.uk>
Cc:        "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>, Current FreeBSD <freebsd-current@freebsd.org>, freebsd-stable@freebsd.org, freebsd-performance@freebsd.org
Subject:   Re: SCHED_ULE should not be the default
Message-ID:  <20111212163221.33d0b8a2@ernst.jennejohn.org>
In-Reply-To: <4EE619FC.4000601@unsane.co.uk>
References:  <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE619FC.4000601@unsane.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Dec 2011 15:13:00 +0000
Vincent Hoffman <vince@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111212163221.33d0b8a2>