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>