Date: Wed, 22 May 2013 11:15:18 -0400 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: Orit Moskovich <oritm@mellanox.com>, freebsd-arch@freebsd.org Subject: Re: FreeBSD spinlock - compatibility layer Message-ID: <201305221115.19093.jhb@freebsd.org> In-Reply-To: <519CC7B4.2030208@mu.org> References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305220905.57939.jhb@freebsd.org> <519CC7B4.2030208@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305221115.19093.jhb>