From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 17:18:20 2010 Return-Path: <owner-freebsd-current@FreeBSD.ORG> Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6C611065679; Wed, 3 Nov 2010 17:18:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A5EC98FC0A; Wed, 3 Nov 2010 17:18:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 52D5846B2D; Wed, 3 Nov 2010 13:18:20 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DE7C38A009; Wed, 3 Nov 2010 13:18:18 -0400 (EDT) From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Date: Wed, 3 Nov 2010 13:17:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <AANLkTi=12-dSAZ21DbZgw36YbRGiUq4KZbyCx3SjucPG@mail.gmail.com> <4CD190EF.5080600@icyb.net.ua> <AANLkTimmiQ9VH=cr+PJ4Hz=h1Oua+ouj7CAv8L__JeNn@mail.gmail.com> In-Reply-To: <AANLkTimmiQ9VH=cr+PJ4Hz=h1Oua+ouj7CAv8L__JeNn@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011031317.36332.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 03 Nov 2010 13:18:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: mdf@freebsd.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: MTX_DEF versus MTX_SPIN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current> List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 03 Nov 2010 17:18:20 -0000 On Wednesday, November 03, 2010 1:04:13 pm mdf@freebsd.org wrote: > On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon <avg@icyb.net.ua> wrote: > > on 03/11/2010 18:27 mdf@FreeBSD.org said the following: > >> It's not clear to me from the man pages (perhaps I didn't look at the > >> right one?) in which environments I need a spinlock. For example, I > >> wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler > >> (i.e one that was registered with BUS_SETUP_INTR), but I see some code > >> lying around here that does it and nothing I'm aware of has broken. > > > > Such a handler runs in an interrupt thread. > > The "harder" interrupt handler is called interrupt filter in FreeBSD terminology. > > I think that it was formerly known as fast interrupt. > > So a MTX_DEF is okay in that environment? Yes. In fact, the reason to have threads for interrupt handlers is to allow interrupt handlers to use non-spin locks that block when the lock is held. MTX_SPIN locks are generally not needed in device drivers. The only reason a driver would use one is if it used a filter handler which does not run in a threaded context. > What would "best practices" be considered for what code should be run > in the interrupt handler versus a soft interrupt? In this case the > kinds of things we have to do at some level of interrupt are: > > - handle a heartbeat interrupt from firmware a few times a second > - get a DMA completion interrupt (completely handling this requires > calling biodone on all the associated bios) > - receive an ECC interrupt (this requires reading registers off the > card for details) > > At the moment we're on stable/7, but we will be migrating the code > base to something more recent in another year or so, if that affects > the answer. I suspect all of these are fine to handle in a regular interrupt handler. If you need to run a task that needs to block on a condition (e.g. cv_*wait*() or *sleep()), then you probably want to use a task to deter that to a taskqueue. At this point taskqueue's are probably the cloest thing FreeBSD really has to a true software interrupt. FreeBSD does have software interrupts still, but the taskqueue API is actually easier to work with for device drivers. > Is there any documentation on best practices for writing a FreeBSD driver? Not really. :-/ -- John Baldwin