Skip site navigation (1)Skip section navigation (2)
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>