Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Dec 2011 07:54:56 -0800
From:      Steve Kargl <sgk@troutmask.apl.washington.edu>
To:        "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>
Cc:        freebsd-performance@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org>, freebsd-stable@freebsd.org
Subject:   Re: SCHED_ULE should not be the default
Message-ID:  <20111213155456.GA93017@troutmask.apl.washington.edu>
In-Reply-To: <4EE751E2.60204@mail.zedat.fu-berlin.de>
References:  <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <20111212155159.GB73597@troutmask.apl.washington.edu> <4EE751E2.60204@mail.zedat.fu-berlin.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 13, 2011 at 02:23:46PM +0100, O. Hartmann wrote:
> On 12/12/11 16:51, Steve Kargl wrote:
> > On Mon, Dec 12, 2011 at 02:47:57PM +0100, 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.
> >>
> >> 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.
> >>
> > 
> > This comes up every 9 months or so, and must be approaching
> > FAQ status.
> > 
> > In a HPC environment, I recommend 4BSD.  Depending on
> > the workload, ULE can cause a severe increase in turn
> > around time when doing already long computations.  If
> > you have an MPI application, simply launching greater
> > than ncpu+1 jobs can show the problem.
> 
> Well, those recommendations should based on "WHY". As the mostly
> negative experiences with SCHED_ULE in highly computative workloads get
> allways contradicted by "...but there are workloads that show the
> opposite ..." this should be shown by more recent benchmarks and
> explanations than legacy benchmarks from years ago.
> 

I have given the WHY in previous discussions of ULE, based
on what you call legacy benchmarks.  I have not seen any
commit to sched_ule.c that would lead me to believe that
the performance issues with ULE and cpu-bound numerical
codes have been addressed.  Repeating the benchmark would
be a waste of time.

-- 
Steve



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