Date: Thu, 15 Dec 2011 19:09:23 +0100 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Steven Hartland <killing@multiplay.co.uk> Cc: tevans.uk@googlemail.com, perryh@pluto.rain.com, attilio@freebsd.org, george+freebsd@m5p.com, "freebsd-current >> Current FreeBSD" <freebsd-current@freebsd.org>, freebsd-stable@freebsd.org, freebsd@jdc.parodius.com Subject: Re: SCHED_ULE should not be the default Message-ID: <4EEA37D3.7000803@zedat.fu-berlin.de> In-Reply-To: <5350EDAC93604B6E93EDBD65A3038F88@multiplay.co.uk> References: <4EE1EAFE.3070408@m5p.com><CAJ-FndDniGH8QoT=kUxOQ%2BzdVhWF0Z0NKLU0PGS-Gt=BK6noWw@mail.gmail.com><4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com><CAFHbX1%2B5PttyZuNnYot8emTn_AWkABdJCvnpo5rcRxVXj0ypJA@mail.gmail.com><4EE933C6.4020209@zedat.fu-berlin.de><20111215004205.GA11556@icarus.home.lan> <4eea1a4a.nJRbEc1jgKpVnVk4%perryh@pluto.rain.com> <5350EDAC93604B6E93EDBD65A3038F88@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCCAE13C8844593D3BFB4F812 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 12/15/11 15:20, schrieb Steven Hartland: > With all the discussion I thought I'd give a buildworld > benchmark a go here on a spare 24 core machine. ULE > tested fine but with 4BSD it wont even boot panicing > with the following:- > http://screensnapr.com/v/hwysGV.png >=20 > This is on a clean 8.2-RELEASE-p4 >=20 > Upgrading to RELENG_9 fixed this but its a bit concerning > that just changing the scheduler would cause the machine > to panic on boot. >=20 > Its only a single run so varience could be high but here's > the result of a buildworld on this machine running the > two different schedulers:- > 4BSD: 24m54.10s real 2h43m12.42s user 56m20.07s sys > ULE: 23m54.68s real 2h34m59.04s user 50m59.91s sys >=20 > What really sticks out is that this is over double that > of an 8.2 buildworld on the same machine with the same > kernel > ULE: 11m12.76s real 1h27m59.39s user 28m59.57s sys >=20 > This was run 9.0-PRERELEASE kernel due to 4BSD panicing > on boot under 8.2. >=20 > So for this use ULE vs 4BSD is neither here-nor-there > but 9.0 buildworld is very slow (x2 slower) compared > with 8.2 so whats a bigger question in my mind. >=20 > Regards > Steve >=20 All of our 8.2-STABLE with ncpu >=3D 4 compile the OS in half the time a compilation of FreeBSD 9/10 is needed to. I guess this is due to the huge LLVM contribution which is now part of the source tree. Even if you allow building a whole LLVM suite (and not even pieces of it as in FreeBSD standard for CLANG purposes), it takes another q0 to 20 minutes, depending on the architecture of the underlying host. Building kernel or worl, taking time and show then the invers of that number isn't a good idea, in my opinion. Therefore I like "artificial" benchmarks: have a set of programs that can be compiled and take the time if compilation time is important. Well, your one-shot test would show, that there is indeed a marginal advantage of SCHED_ULE, if the number of cores is big enough (as said to be n > 2 in this thread). But I'm a bit disappointed about the very small advantage on that 24 core hog. Oliver --------------enigCCAE13C8844593D3BFB4F812 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQEcBAEBAgAGBQJO6jfTAAoJEOgBcD7A/5N88mQIAKwvLo61jfJiVhjqNhN81imb HcZAcGb0Apy+ijC/Q9v9HjQbWSoPk3HeENyt5iYXV421WoYXy94qP0vO67yV0H2K 10UbVfIh5XmYfz89WdIjS4HvdmPKSjYnsZ17m93sJY4oWS8iO9nDwi1Z+K9h2LaD 6jN2hEFuGk547Yr3nTbKnXlm04CKp8sG+XIzbDhwDu+uB7FdkHH9NDi2w3Ki2f52 zSozarItiCqb/Ec0DAtGHAUoE25W5Tg+CshqZgdJXzWfFVrIbI+uXNx1AxhN4t91 rJ014tPDG+4UnqTprJ+5EtxO1Hpcqn7SmZ4jZfWE5aCmxkvXaE3koZvkzzpphRo= =r3lZ -----END PGP SIGNATURE----- --------------enigCCAE13C8844593D3BFB4F812--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EEA37D3.7000803>