From owner-freebsd-arch@FreeBSD.ORG Fri May 24 02:27:05 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 64648C6A; Fri, 24 May 2013 02:27:05 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 390F9F84; Fri, 24 May 2013 02:27:04 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-237-17.lns20.per1.internode.on.net [121.45.237.17]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r4O2QwPt077268 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 23 May 2013 19:27:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <519ECFED.9050602@freebsd.org> Date: Fri, 24 May 2013 10:26:53 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: FreeBSD spinlock - compatibility layer References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305220905.57939.jhb@freebsd.org> <519CC7B4.2030208@mu.org> <201305221115.19093.jhb@freebsd.org> In-Reply-To: <201305221115.19093.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alfred Perlstein , 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: Fri, 24 May 2013 02:27:05 -0000 On 5/22/13 11:15 PM, 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. > in the *mumble* (company I worked for recently) compat layer, we used mutexes to implement the "spinlock" that the linux driver used when it was run under FreeBSD.. It really didn't need a spinlock, it's just that by default linux drivers do/did so.