From owner-freebsd-arch@FreeBSD.ORG Wed May 22 14:21:34 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0D164BC3 for ; Wed, 22 May 2013 14:21:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id D28946B9 for ; Wed, 22 May 2013 14:21:33 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k5so5285668iea.32 for ; Wed, 22 May 2013 07:21:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cEbJza/JjZLJ9SEwa1GTBW4WOF/dGoZ6X8RrQNpNX2I=; b=e+4P9L/leN1TmDJHxwha3Svla2whnfhDd4hM2PRAT2xGDDZqYF1sAmp7s1wy8IrJfp x5MBGnr5hFPH1g26hGnqr9cfyFhmj/oxxS8jvsMNXdH2RdYQyCg1ePuGFzELHcKtRpWX ifN7cCJdgA/zXxRz8Zac/JiK2cFxihQcMufO422njzzFfVN7+n9vfGlcsSx21NOJA4HP y+qrghv+xvMwbex5O9M/UIf7AdYQ/2+eBtN1j2FmI/PKkkosCrPAF1Xep7paCkF5gZoM b8SSF4G3ugiCVqgEueTih7SqrsWPc7yOQrrNC5cLkQ5ipINkpF97+LJZZs/T8xxqKJ8P Itqw== X-Received: by 10.42.50.202 with SMTP id b10mr6126713icg.7.1369232493543; Wed, 22 May 2013 07:21:33 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id l14sm7283741igf.9.2013.05.22.07.21.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 May 2013 07:21:32 -0700 (PDT) Sender: Warner Losh Subject: Re: FreeBSD spinlock - compatibility layer Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com> Date: Wed, 22 May 2013 08:21:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <981733489AB3BD4DB24B48340F53E0A55B0CFD79@MTLDAG01.mtl.com> <201305200950.26834.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D091F@MTLDAG01.mtl.com> <201305211220.16776.jhb@freebsd.org> <981733489AB3BD4DB24B48340F53E0A55B0D39EF@MTLDAG01.mtl.com> To: Orit Moskovich X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnVQt98hmf7IsFVSbgtXfzbNzPc0J98ARsL4FE+s9WzvKrkhkpvSSousJsyS9xoMja9qbRx 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 14:21:34 -0000 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"