Date: Wed, 08 Jan 2014 23:30:30 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> 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: <52CDC376.5040302@FreeBSD.org> In-Reply-To: <20140108185912.GU59496@kib.kiev.ua> References: <CAJ-Vmok-AJkz0THu72ThTdRhO2h1CnHwffq=cFZGZkbC=cWJZA@mail.gmail.com> <52CD7D07.2010608@FreeBSD.org> <20140108185912.GU59496@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 08/01/2014 20:59 Konstantin Belousov said the following: > On Wed, Jan 08, 2014 at 06:29:59PM +0200, Andriy Gapon wrote: >> >> 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 record >> 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. > > Isn't this exactly the mechanism offered by turnstiles, and used by > non-sleepable locks ? 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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52CDC376.5040302>