Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 May 2013 08:21:30 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Orit Moskovich <oritm@mellanox.com>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: FreeBSD spinlock - compatibility layer
Message-ID:  <C0769228-4A33-4ADC-90B9-E7D55F1F7113@bsdimp.com>
In-Reply-To: <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com>
References:  <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305200950.26834.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D091F@MTLDAG01.mtl.com> <201305211220.16776.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On May 22, 2013, at 12:14 AM, Orit Moskovich wrote:

> =46rom what I've read in "FreeBSD - device drivers" book by Joseph =
Kong on interrupt handling, you cannot voluntarily context switch (that =
is, sleep) in interrupt threads .

In ithreads, the interrupt thread context, you can voluntarily context =
switch. In a interrupt filter you can't, but that's because you are =
running in an interrupt context. Please note that an interrupt context =
and an interrupt thread context are different things.

> In any case, I think that the functionality of spin mutex should =
remain as is, and not modified to sleep mutex, as it can be used in =
places that sleep mustn't be used, or that require the properties of the =
spin due to performance considerations.

The linux compat layer is just for the oled stuff. It isn't intended to =
be a complete 'drop in' replacement environment for Linux drivers. =
Anything at odds with this basic purpose is unlikely to happen.

Warner

>=20
>=20
> -----Original Message-----
> From: John Baldwin [mailto:jhb@freebsd.org]=20
> Sent: Tuesday, May 21, 2013 10:02 PM
> To: Orit Moskovich
> Cc: freebsd-arch@freebsd.org
> Subject: Re: FreeBSD spinlock - compatibility layer
>=20
> On Tuesday, May 21, 2013 12:36:38 am Orit Moskovich wrote:
>> That's not the case when using taskqueues for deferring  execution of=20=

>> an
> interrupt handler.
>> Tasks can be delayed using the global taskqueue taskqueue_swi, which
> executes its tasks in the context of an interrupt.
>> In this case sleep is forbidden, and using spin mutex is not =
(although=20
>> might
> be not recommended).
>=20
> No, swi's run in an interrupt thread, and interrupt threads can use =
regular mutexes.  (That is why they run in a thread context.)  The only =
way you can run in a context requiring a spin lock in a driver is to use =
an interrupt filter.
>=20
> --
> John Baldwin
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to =
"freebsd-arch-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0769228-4A33-4ADC-90B9-E7D55F1F7113>