From owner-freebsd-stable@FreeBSD.ORG Tue Dec 13 15:54:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B0C9106564A; Tue, 13 Dec 2011 15:54:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id BD1178FC12; Tue, 13 Dec 2011 15:54:56 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pBDFsuaL093141; Tue, 13 Dec 2011 07:54:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pBDFsuJ2093140; Tue, 13 Dec 2011 07:54:56 -0800 (PST) (envelope-from sgk) Date: Tue, 13 Dec 2011 07:54:56 -0800 From: Steve Kargl To: "O. Hartmann" Message-ID: <20111213155456.GA93017@troutmask.apl.washington.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE751E2.60204@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-performance@freebsd.org, Current FreeBSD , freebsd-stable@freebsd.org Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 15:54:57 -0000 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