Date: Mon, 20 Feb 2017 16:24:50 -0800 From: Bryan Drewery <bdrewery@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r313878 - head/sys/kern Message-ID: <e7d7c961-ec3b-22bc-445e-abe56e421e5c@FreeBSD.org> In-Reply-To: <201702171540.v1HFeOAs074991@repo.freebsd.org> References: <201702171540.v1HFeOAs074991@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kVEIfWq9SblPLUh7OsVUDtBiWAINK05s1 Content-Type: multipart/mixed; boundary="rKFqnbGm2nTr9E3MqE9oBvKT0EXpCE3ii"; protected-headers="v1" From: Bryan Drewery <bdrewery@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-ID: <e7d7c961-ec3b-22bc-445e-abe56e421e5c@FreeBSD.org> Subject: Re: svn commit: r313878 - head/sys/kern References: <201702171540.v1HFeOAs074991@repo.freebsd.org> In-Reply-To: <201702171540.v1HFeOAs074991@repo.freebsd.org> --rKFqnbGm2nTr9E3MqE9oBvKT0EXpCE3ii Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/17/2017 7:40 AM, Mateusz Guzik wrote: > Author: mjg > Date: Fri Feb 17 15:40:24 2017 > New Revision: 313878 > URL: https://svnweb.freebsd.org/changeset/base/313878 >=20 > Log: > mtx: get rid of file/line args from slow paths if they are unused > =20 > This denotes changes which went in by accident in r313877. I really wish people would just revert their changes and recommit them properly. The 'svn blame' on the code in r313877 will never show the commit message here (r313878). So a person would only find this explanation if they read 'svn log' on the file, which in the case of sys/kern/kern_mutex.c there are 273 commits for. Are we expected to read 'svn log' (in the future) for all changes in the hopes that a later commit happens to mention it? As someone who so often is 'svn blame'ing code to understand it better and to track regressions, commits like this that explain other commits might as well have never been done. > =20 > On most production kernels both said parameters are zeroed and have n= othing > reading them in either __mtx_lock_sleep or __mtx_unlock_sleep. Thus t= his change > stops passing them by internal consumers which this is the case. > =20 > Kernel modules use _flags variants which are not affected kbi-wise. >=20 > Modified: > head/sys/kern/kern_mutex.c >=20 > Modified: head/sys/kern/kern_mutex.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sys/kern/kern_mutex.c Fri Feb 17 15:34:40 2017 (r313877) > +++ head/sys/kern/kern_mutex.c Fri Feb 17 15:40:24 2017 (r313878) > @@ -622,7 +622,7 @@ __mtx_lock_sleep(volatile uintptr_t *c,=20 > LOCKSTAT_RECORD1(adaptive__block, m, sleep_time); > =20 > /* > - * Only record the loops spinning and not sleeping.=20 > + * Only record the loops spinning and not sleeping. > */ > if (lda.spin_cnt > sleep_cnt) > LOCKSTAT_RECORD1(adaptive__spin, m, all_time - sleep_time); >=20 --=20 Regards, Bryan Drewery --rKFqnbGm2nTr9E3MqE9oBvKT0EXpCE3ii-- --kVEIfWq9SblPLUh7OsVUDtBiWAINK05s1 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 iQEcBAEBAgAGBQJYq4jSAAoJEDXXcbtuRpfPGo8H/jz11bazy9RQvaXBS9FLsnjC +h3+UP7e0VsOY3OK5t6hCA1/7eOjrg8RunC1iULUD3Lg6GeGvWk7bSXjgJnEqMRF tToqXvyjh7X7QnyWUIJdaAEZb8XubFxdeYx4e0sQrjhLqpTuSngjh3G+T6Ou1ezR z1Fo0QHYvI+HDEAZ0/2Xi9pLZDMIMaab05vt4frnVNOocj1GFegeGIUj5zXmxeZQ gmt/Z++SAR8jFXqq3uEWkDEMsF/O5iTkB+6JNzhdNv8szC3yflQyQxrjydAsOcZH 60sL+VFRqH2T1jrtW8vGq72uiUB0B//QUsZCV3YT2oTA7qp/umcD1FL6pHR2CbU= =SLH4 -----END PGP SIGNATURE----- --kVEIfWq9SblPLUh7OsVUDtBiWAINK05s1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7d7c961-ec3b-22bc-445e-abe56e421e5c>