Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 May 2013 04:36:38 +0000
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
Message-ID:  <981733489AB3BD4DB24B48340F53E0A55B0D091F@MTLDAG01.mtl.com>
In-Reply-To: <201305200950.26834.jhb@freebsd.org>
References:  <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305200950.26834.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?981733489AB3BD4DB24B48340F53E0A55B0D091F>