Date: Thu, 10 Nov 2016 08:52:07 +0100 From: Hans Petter Selasky <hps@selasky.org> To: John Baldwin <jhb@freebsd.org> Cc: Oleksandr Tymoshenko <gonzo@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Marshall Kirk McKusick <mckusick@mckusick.com> Subject: Re: svn commit: r308424 - head/sys/arm/broadcom/bcm2835 Message-ID: <6bce6a4b-d782-77af-8515-7243eab38cf3@selasky.org> In-Reply-To: <2064206.nvhhXHc9vW@ralph.baldwin.cx> References: <201611071738.uA7HceYu045944@repo.freebsd.org> <3214848.geWV8qu7rM@ralph.baldwin.cx> <5c170b6b-1189-4712-ffdd-653cc6b8c59e@selasky.org> <2064206.nvhhXHc9vW@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 11/09/16 17:32, John Baldwin wrote: > It isn't predicted and avoided by turnstiles. In particular, the cv_signal has > no idea what lock is associated, so it can't try to do something "smart" and > move the thread from the sleepq to the lockq. You will pay the double context > switch. Maybe this is an idea for a turnstile optimisation? In another embedded OS based on FreeBSD I did exactly this. If someone is sleeping through cv_wait() the lock it is sleeping on, if different from NULL, is stored in the sleepqueue. When cv_signal() is invoked we simply check if the saved lock is owned by the caller and then don't do the pre-emption, because we predict it will be locked by cv_wait() before returning. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6bce6a4b-d782-77af-8515-7243eab38cf3>