From owner-freebsd-arch@FreeBSD.ORG Wed May 22 06:15:22 2013 Return-Path: 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 0C3E8683; Wed, 22 May 2013 06:15:22 +0000 (UTC) (envelope-from oritm@mellanox.com) Received: from eu1sys200aog121.obsmtp.com (eu1sys200aog121.obsmtp.com [207.126.144.151]) by mx1.freebsd.org (Postfix) with ESMTP id EBE3AB29; Wed, 22 May 2013 06:15:20 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob121.postini.com ([207.126.147.11]) with SMTP ID DSNKUZxiXWsBN4kQBPT+F8RhMSLHf6oqsFxh@postini.com; Wed, 22 May 2013 06:15:21 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; Wed, 22 May 2013 09:14:52 +0300 From: Orit Moskovich To: John Baldwin Subject: RE: FreeBSD spinlock - compatibility layer Thread-Topic: FreeBSD spinlock - compatibility layer Thread-Index: Ac5QiaSgCms1CiujRJ+uiUawknitKQEvjFEAACUK0bAAEntnAAAi8Btg Date: Wed, 22 May 2013 06:14:51 +0000 Message-ID: <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com> References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305200950.26834.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D091F@MTLDAG01.mtl.com> <201305211220.16776.jhb@freebsd.org> In-Reply-To: <201305211220.16776.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 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 06:15:22 -0000 >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