From owner-freebsd-performance@FreeBSD.ORG Tue Dec 13 21:58:23 2011 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1D9106566B; Tue, 13 Dec 2011 21:58:23 +0000 (UTC) (envelope-from malin.randstrom@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF768FC12; Tue, 13 Dec 2011 21:58:23 +0000 (UTC) Received: by ggnp1 with SMTP id p1so178082ggn.13 for ; Tue, 13 Dec 2011 13:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sNUT/fjw6EchSejWXjJP78ubljFlvCF9/iUH/FOJoMw=; b=PfIJj08Hg3htPuqeML1U2v1eJXBM77qQyqpdPPq+VNEjSULs4zPKRI2Bu18wWL237o qEd1GrX4vdWLE4fWlX5YDR87QWLA8rFXDsoHM0bOJHPTeLEVpYw+5yK3zG3cQrDSn+OU AfZ94IGdq58983Kbm6A1Y3ZAN9v/1UPA4MGOw= MIME-Version: 1.0 Received: by 10.182.218.100 with SMTP id pf4mr4801602obc.12.1323811881013; Tue, 13 Dec 2011 13:31:21 -0800 (PST) Received: by 10.182.6.133 with HTTP; Tue, 13 Dec 2011 13:31:20 -0800 (PST) Received: by 10.182.6.133 with HTTP; Tue, 13 Dec 2011 13:31:20 -0800 (PST) In-Reply-To: <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> <20111213155456.GA93017@troutmask.apl.washington.edu> Date: Tue, 13 Dec 2011 22:31:20 +0100 Message-ID: From: Malin Randstrom To: Steve Kargl X-Mailman-Approved-At: Wed, 14 Dec 2011 18:00:27 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-performance@freebsd.org, Current FreeBSD , freebsd-stable@freebsd.org, "O. Hartmann" Subject: Re: SCHED_ULE should not be the default X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: malin@randstrom.com List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 21:58:23 -0000 stop sending me spam mail ... you never stop despite me having unsubscribeb several times. stop this! On Dec 13, 2011 8:12 PM, "Steve Kargl" wrote: > 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 > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" >