Date: Thu, 9 Jan 2014 07:31:13 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Adrian Chadd <adrian@FreeBSD.org>, "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> Subject: Re: Acquiring a lock on the same CPU that holds it - what can be done? Message-ID: <20140109053113.GW59496@kib.kiev.ua> In-Reply-To: <52CDC376.5040302@FreeBSD.org> References: <CAJ-Vmok-AJkz0THu72ThTdRhO2h1CnHwffq=cFZGZkbC=cWJZA@mail.gmail.com> <52CD7D07.2010608@FreeBSD.org> <20140108185912.GU59496@kib.kiev.ua> <52CDC376.5040302@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--eJIwejkrNE5TYv+U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 08, 2014 at 11:30:30PM +0200, Andriy Gapon wrote: > on 08/01/2014 20:59 Konstantin Belousov said the following: > > On Wed, Jan 08, 2014 at 06:29:59PM +0200, Andriy Gapon wrote: > >>=20 > >> I am sure that the following approach was suggested before, but I can = not > >> find any references now. So, the idea is to auto-associate a priority > >> with a lock. Every time a priority lending would kick in we would rec= ord > >> the priority in the lock. The next time a thread with a lower priority > >> acquires that lock we would automatically boost the thread to the > >> recorded priority until it releases the lock. This should prevent the > >> situation that you've described where a higher priority thread preempts > >> a lower priority thread just to discover that it holds a required lock > >> and priority lending is required before relinquishing a CPU to the > >> preempted thread. > >=20 > > Isn't this exactly the mechanism offered by turnstiles, and used by=20 > > non-sleepable locks ? >=20 > No, as far as I can see. The current mechanism is to lend priority when > contention happens. The proposal is to remember the maximal (numerically > minimal) lent priority and thus to prevent potentially contending threads= from > even running on the same CPU. I.e. you propose to extend the prioriry propagation to all cases of lock acquisition. This is not quite correct as well, but now in the other direction, since it prevents non-contending high-priority thread from running. I think a good experiment would be to add critical_enter/critical_exit to non-sleepable locks and see. --eJIwejkrNE5TYv+U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSzjQgAAoJEJDCuSvBvK1BxR4P/Awzcuz4tjn79uM7Ywg07SA/ C36qc48zvYtmWTBDrr2EmVqw+clwpSp/vknK17FjIaeQY+HES5AaOmr2dmAC0Fx+ p+8N6iR4/+ajkKvxw6qew31KRsDWtRGlwNq+VyGKcJmplQ64mbil1G/mru2yll1r 6/1UEOnCuSq29uHppKJFlr8kTEtMMYd+skc2gVh8yA+0ar76k7yTtXxCNyj7d/bs CnMmnG34BUHzGLhh/JKzNUt3CLzce8rDGck2Ln2bbpZYOjCN+HhdQEy1JvE8wSGj F5DeUvtLO50wEHp3hztPQnJDHe6M1WqAsFGiqoLKCxDQpBtHXBtmhaHgEWwRRJne uBpFjcySh+qKowUT7pLXrxQS4OdKdi30ZHLGPfxMYKXYq263Odr/FU+Jrosiqv4S 1ZNkAkfr7OU4IkGh7oFkMNIXVzWGknn6UBUgvKMaPcJEw7FzWG3mwTRovHiTCixm wOYvdH9UU8bYzmMa1yccHIbmW80rhDfZDcRWdmmQ86dF/2w1Ouguz86saEdjX1Yv q4upTF6PpgfCkDgFT7cwOThDtUlqLrr/YCoDq0xURPt8ZYRwxjTVSvb889ZyY5lP lQv+LqipZTv1aEbVCpM8j6J/Sol1Rcidh+6rQvbmj7IvxS/PsNgtC4oTzDjU29HG VlPgntrp9isPb9mv/dxY =ftsm -----END PGP SIGNATURE----- --eJIwejkrNE5TYv+U--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140109053113.GW59496>