Date: Wed, 22 May 2013 06:14:51 +0000 From: Orit Moskovich <oritm@mellanox.com> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: RE: FreeBSD spinlock - compatibility layer Message-ID: <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com> In-Reply-To: <201305211220.16776.jhb@freebsd.org> References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305200950.26834.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D091F@MTLDAG01.mtl.com> <201305211220.16776.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>From what I've read in "FreeBSD - device drivers" book by Joseph Kong on in= terrupt handling, you cannot voluntarily context switch (that is, sleep) in= interrupt threads . 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 perform= ance considerations. -----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 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). 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 ca= n run in a context requiring a spin lock in a driver is to use an interrupt= filter. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?981733489AB3BD4DB24B48340F53E0A55B0D39EF>