Date: Tue, 20 Mar 2018 23:08:15 +0100 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@freebsd.org Subject: Re: Stability of 11.1S Message-ID: <20180320220815.GA14152@plan-b.pwste.edu.pl> In-Reply-To: <20180320181047.GA55267@icarus.home.lan> References: <20180320181047.GA55267@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--KsGdsel6WgEHnImy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2018 at 11:10:47AM -0700, Jeremy Chadwick wrote: > (Please keep me CC'd as I am not subscribed to -stable) >=20 > I haven't seen any issues, but that means very little. Details: >=20 > Two boxes -- one bare metal, one VPS (QEMU): >=20 > $ uname -a > FreeBSD XXXXXXXXXXXXXXX 11.1-STABLE FreeBSD 11.1-STABLE #0 r330529: Tue M= ar 6 11:36:04 PST 2018 root@XXXXXXXXXXXXXXX:/usr/obj/usr/src/sys/X7SBA= _RELENG_11_amd64 amd64 > $ uptime > 10:33a.m. up 13 days, 18:10, 2 users, load averages: 0.15, 0.19, 0.16 >=20 > $ uname -a > FreeBSD XXXXXXXXXXXXXXXX 11.1-STABLE FreeBSD 11.1-STABLE #0 r330753: Sat = Mar 10 21:34:20 PST 2018 root@XXXXXXXXXXXXXXXX:/usr/obj/usr/src/sys/XXX= XXXXX_RELENG_11_amd64 amd64 > $ uptime > 10:33a.m. up 9 days, 10:46, 1 user, load averages: 0.31, 0.35, 0.31 >=20 > Systems were updated recently because I wanted to test Meltdown/Spectre > mitigation (more on that below). Prior to that, bare metal was running > 9.x with 200+ day uptimes, VPS was running 10.x with 80-90 day uptimes > (VPS providers' HV crashed, i.e. not FreeBSD issues). >=20 > Since load averages on FreeBSD 10.x onward cannot be trusted[1][2], I > have to explain the general system specs and loads: >=20 > Bare metal box is an Intel Core 2 Quad Q9550, 8GB RAM, doing very little > other than running Apache + lots of cron jobs for systems stuff + ZFS > with several disks (but not OS disk; that's a dedicated SSD w/ UFS + SU > (not SUJ). The cron jobs tend to stress the network and disk I/O a bit; > ZFS gets used every day, but only "heavily" during LAN file copies > to/from it (Samba is involved), and during nightly backups with rsync. >=20 > VPS box is some form of QEMU-based Intel Haswell CPU, 1GB RAM, doing > general things like Apache + postfix + SpamAssassin + some other > daemons, and a lot of Perl. Swap is used heavily on this machine. > Disks are all vtblk, and I use multiple to get capacity for the needed > space for /usr/src and /usr/obj. Everything is UFS + SU (not SUJ). >=20 > Things off the top of my head that might be relevant to you: >=20 > 1. r329462 added Meltdown/Spectre mitigation[3][4]. >=20 > Bare metal box has the below in /boot/loader.conf, since this is a > machine that does not need either given its environment: >=20 > # Disable PTI (Meltdown mitigation) and IBRS (Spectre mitigation); these > # are not relevant on this bare-metal system given its environment and > # use case. Details of these tunables is here: > # https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526.ht= ml > # > vm.pmap.pti=3D"0" > hw.ibrs_disable=3D"1" >=20 > VPS box has no tunings of this sort, and ends up with the below, because > the hosting provider has no done BIOS + QEMU updates to add IBRS > support (they're very aware of it + have attempted it twice but > apparently it didn't go well): >=20 > vm.pmap.pti: 1 > hw.ibrs_disable: 1 > hw.ibrs_active: 0 >=20 > 2. If your CPU is an AMD Ryzen, there is a VERY long discussion on > -stable about problems with Ryzen manifesting itself in a very > uncomfortable way, leading to system lock-ups[5]. There are unofficial > patches you can try. I would recommend chiming in there and not here, > if relevant to your systems. >=20 > And yes, the massive number of MFCs that eadler@ is doing make tracking > down exact things more tedious than normal, especially when you have > sweeping commits like this one[6][7] (which, AFAIK, was acting as a > major blocker for several other MFCs and causing general merge > problems). >=20 > However, I commend his efforts; it's a massive undertaking (I would say > full-time job). We stable users must accept that we are running > stable/11 for a reason -- not only to get fixes faster, but to act a > form of "guinea pig" that don't want the risks of HEAD/CURRENT. The > more people using stable/11 the better overall feedback devs can get on > bugs/issues before making it into the next -RELEASE. This is exactly > why, for those of you who have known me over the years, I actually > "track" or "follow" commits as they come across. I do this by using the > FreshBSD site[8] alongside manual review of svnlite update output. I > generally know what files/bits are relevant to my interests. >=20 > Hope this gives you some things to think about. Good luck! >=20 > [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D173541#c8 > [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D173541#c22 > [3]: https://lists.freebsd.org/pipermail/freebsd-stable/2018-February/088= 396.html > [4]: https://lists.freebsd.org/pipermail/freebsd-stable/2018-March/088526= =2Ehtml > [5]: https://lists.freebsd.org/pipermail/freebsd-stable/2018-January/thre= ad.html#88174 > [6]: http://www.freshbsd.org/commit/freebsd/r330897 > [7]: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D330897 > [8]: http://www.freshbsd.org/?branch=3DRELENG_11&project=3Dfreebsd >=20 I follow STABLE uprgrading regularly bunch of servers, routers, PCs, laptop and even sometimes Raspberry Pi, always using builds made with meta mode without any serious issue in last months.=20 If I may put my two cents in, the term "guinea pigs" seems to be adequate definition here, but the old school of STABLE users although dying, as the whole BSD is, is still alive, despite a few premature MFCs, imprudent CoCs etc. STABLE seems to be all the same stable. I guess we should rather appreciate the efforts of commiters merging not only bug fixes but also new features than criticize every unattended MFC. --=20 Marek Zarychta --KsGdsel6WgEHnImy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlqxhksACgkQdZ/s//1S jSziogf/dnkx8v5vtdnQ3613fmmgy3kKQv/7h1YSegXfXJp7niQbKbuKhCE8ccKk 5Q+zheDj1plkyrcorRuTPRzBFzXID/jnDm7fuWMPYNpQpaxXjCl4kcsO3S+S3f5p OBNznbHljm22X2gk8Ae46V9sr2R8UF1Ua2DPFrr0Elg0YIRH3g+XSnsT00mr3pMq hp+u6EbOiX+O038Vx8qNXnfU8WSuOVpUGAQtcVl7t8uwxOHvQx86Kmz+VZj61Ey9 vYLHu5QtVBx02EDCLz8I25OUcRfz3OKw76VfOAJAlJF+PUpIhAOyrjaOamKUczRn KVBgRWx0viIO5bCC51UwqfsxLlf1wA== =Czju -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180320220815.GA14152>