From owner-freebsd-arch@FreeBSD.ORG  Tue May 21 04:37:08 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 4A820685;
 Tue, 21 May 2013 04:37:08 +0000 (UTC)
 (envelope-from oritm@mellanox.com)
Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com
 [207.126.144.143])
 by mx1.freebsd.org (Postfix) with ESMTP id 4607CE55;
 Tue, 21 May 2013 04:37:06 +0000 (UTC)
Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by
 eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP
 ID DSNKUZr52KACssjLF3AlUVKoawGEPu+PIZN7@postini.com;
 Tue, 21 May 2013 04:37:07 UTC
Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com
 ([10.0.8.71]) with mapi id 14.03.0123.003; Tue, 21 May 2013 07:36:39 +0300
From: Orit Moskovich <oritm@mellanox.com>
To: John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org"
 <freebsd-arch@freebsd.org>
Subject: RE: FreeBSD spinlock - compatibility layer
Thread-Topic: FreeBSD spinlock - compatibility layer
Thread-Index: Ac5QiaSgCms1CiujRJ+uiUawknitKQEvjFEAACUK0bA=
Date: Tue, 21 May 2013 04:36:38 +0000
Message-ID: <981733489AB3BD4DB24B48340F53E0A55B0D091F@MTLDAG01.mtl.com>
References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com>
 <201305200950.26834.jhb@freebsd.org>
In-Reply-To: <201305200950.26834.jhb@freebsd.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.0.13.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 04:37:08 -0000

That's not the case when using taskqueues for deferring  execution of an in=
terrupt handler.
Tasks can be delayed using the global taskqueue taskqueue_swi, which execut=
es its tasks in the context of an interrupt.
In this case sleep is forbidden, and using spin mutex is not (although migh=
t be not recommended).


-----Original Message-----
From: John Baldwin [mailto:jhb@freebsd.org]=20
Sent: Monday, May 20, 2013 11:42 PM
To: freebsd-arch@freebsd.org
Cc: Orit Moskovich
Subject: Re: FreeBSD spinlock - compatibility layer

On Tuesday, May 14, 2013 6:04:21 am Orit Moskovich wrote:
> Hi,
>=20
> I read about the FreeBSD mutex implementation for spinlock in the
compatibility layer.
> I might be wrong, but I noticed a code section that might be problematic:
>=20
> Taken from
http://svn.freebsd.org/base/release/9.1.0/sys/ofed/include/linux/spinlock.h=
:
>=20
> static inline void
> spin_lock_init(spinlock_t *lock)
> {
>=20
>         memset(&lock->m, 0, sizeof(lock->m));
>         mtx_init(&lock->m, "lnxspin", NULL, MTX_DEF | MTX_NOWITNESS);=20
> }
>=20
> But MTX_DEF initializes mutex as a sleep mutex:
>=20
> By default, MTX_DEF mutexes will context switch when they are already
>=20
>      held.
>=20
>=20
> There is a flag MTX_SPIN Which I think is the right one in this case .
>=20
>=20
>=20
> I'd appreciate your take on this issue.

Since FreeBSD uses a different approach to interrupt handlers (they run in =
threads, not in the bottom half), a regular mutex may in fact give the clos=
est match to the same semantics.  Regular mutexes are also cheaper and in g=
eneral preferable to spin mutexes whenever possible.

--
John Baldwin