Date: Tue, 13 Dec 2011 14:23:46 +0100 From: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de> To: Steve Kargl <sgk@troutmask.apl.washington.edu> 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: <4EE751E2.60204@mail.zedat.fu-berlin.de> In-Reply-To: <20111212155159.GB73597@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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B23B528A575FB784F3E4BE3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 planeta= ry >> 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 wh= o >> 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 bo= th >> different schedulers available. >> >=20 > This comes up every 9 months or so, and must be approaching > FAQ status. >=20 > 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. And, indeed, I highly would recommend having a FAQ or a short note in "tuning" or the handbook in which it is mentioned to use SCHED_4BSD in HPC environments and SCHED_ULE for other workloads (which has to be more specific). It is not an easy task setting up a certain kind of OS for a specific purpose and tuning by crawling the mailing lists. Some notes and hints in the documentation is always a valuable hint and highly appreciated by folks not deep into development. And by the way, I have the deep impression that most of these discussions about the poor performance of SCHED_ULE tend to always end up in a covering up that flaw and the conclusive waste of development. But this is only my personal impression. --------------enig1B23B528A575FB784F3E4BE3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7nUegACgkQU6Ni+wtCKv9RzAD9GhKwCryupmWNA64Wp5N7rMzk +WcXFTQXR19FqiE3OkMA/3PRpLaK7SJcAh3PiyujWMGBt1smTuui80KUWTatd5+5 =SLRk -----END PGP SIGNATURE----- --------------enig1B23B528A575FB784F3E4BE3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE751E2.60204>