From owner-freebsd-arch@FreeBSD.ORG Thu Jan 9 05:31:24 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA479424; Thu, 9 Jan 2014 05:31:24 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2CF1CD5; Thu, 9 Jan 2014 05:31:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s095VDB7068678; Thu, 9 Jan 2014 07:31:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s095VDB7068678 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s095VDCX068677; Thu, 9 Jan 2014 07:31:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Jan 2014 07:31:13 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Acquiring a lock on the same CPU that holds it - what can be done? Message-ID: <20140109053113.GW59496@kib.kiev.ua> References: <52CD7D07.2010608@FreeBSD.org> <20140108185912.GU59496@kib.kiev.ua> <52CDC376.5040302@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJIwejkrNE5TYv+U" Content-Disposition: inline In-Reply-To: <52CDC376.5040302@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Adrian Chadd , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 05:31:24 -0000 --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--