From owner-freebsd-arch@FreeBSD.ORG Wed May 22 21:50:32 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 302487F4 for ; Wed, 22 May 2013 21:50:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC09A3A for ; Wed, 22 May 2013 21:50:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 48C86B99A; Wed, 22 May 2013 17:50:31 -0400 (EDT) From: John Baldwin To: Alfred Perlstein Subject: Re: FreeBSD spinlock - compatibility layer Date: Wed, 22 May 2013 13:14:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305221115.19093.jhb@freebsd.org> <519CF32D.2040609@mu.org> In-Reply-To: <519CF32D.2040609@mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305221314.25663.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 May 2013 17:50:31 -0400 (EDT) Cc: Orit Moskovich , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 21:50:32 -0000 On Wednesday, May 22, 2013 12:32:45 pm Alfred Perlstein wrote: > On 5/22/13 11:15 AM, John Baldwin wrote: > > On Wednesday, May 22, 2013 9:27:16 am Alfred Perlstein wrote: > >> On 5/22/13 9:05 AM, John Baldwin wrote: > >>> Probably not. For example, on FreeBSD you want your driver lock to be > >>> preempted by an interrupt to avoid higher interrupt latency for filter > >>> handlers. Most drivers should not need temporary pinning. If they want to > >>> pin work to threads they should bind threads or IRQs to specific CPUs, not > >>> rely on temporary pinning. > >>> > >> I know how it works in FreeBSD. > >> > >> I think that a compatibility layer should first and foremost aim for > >> compatibility, not speed at expense of expected semantics. > > The problem with this is that whatever code runs under this layer also has to > > cooperate with the rest of the system. Blindly using spin locks does not do > > that. Also, I think my entire point is about "expected semantics". People > > should think about the actual semantics they need in a driver, not just assume > > that whatever side effects they get from the primitives and APIs provided on > > one platform defines the semantics they need. I still assert that in terms of > > what a device driver actually expects, a regular mutex will provide the correct > > semantics. > > > I agree with your assertion that what we have MTX_DEF should work for > drivers for the cases we have. > > I do believe though that any kernel dev outside FreeBSD will expect > certain semantics from a spin mutex though. No, not on Solaris. Probably not on some dinosaur UNIXes (Irix had adaptive mutexes for example). -- John Baldwin