From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 22:17:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D15DA16A4CE for ; Fri, 12 Nov 2004 22:17:50 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32C3F43D45 for ; Fri, 12 Nov 2004 22:17:50 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iACMJYZn006364; Fri, 12 Nov 2004 15:19:34 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <419536C0.5040807@freebsd.org> Date: Fri, 12 Nov 2004 15:18:40 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20041112.143439.33211003.imp@bsdimp.com> <41952FBD.40602@freebsd.org> <20041112.150905.105578119.imp@bsdimp.com> In-Reply-To: <20041112.150905.105578119.imp@bsdimp.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: usb with fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 22:17:50 -0000 M. Warner Losh wrote: > In message: <41952FBD.40602@freebsd.org> > Scott Long writes: > : M. Warner Losh wrote: > : > Our usb system supports soft interrupts, but we currently don't make > : > productive use of them. The following makes interrupts fast > : > interrupts and uses taskqueues to queue data to a SWI. > : > > : > Lemme know if it works for you. > : > > : > Warner > : > > : > : Taskqueues aren't good for timing-sensitive operations. Even though USB > : may not be terribly sensitive, I bet you'll actually see performance > : drops with things like umass with this. Could you instead just put the > : real handler into a kthread and wake it up, or use a swi? > > I'll have to measure, but I've not seen my umass get any slower with > this patch... I can't use a SWI, because there's no way to turn off > an SWI once you've created it (and I think you'd said you were opposed > to creating a SWI cleanup function). I'm not sure how a kthread would > be any faster, however, since both a taskqueue and a thread have to go > through a scheduling point. > > A quick test here seems to point out a bug in da: > sudo dd if=/dev/da0 of=/dev/null > ^C5275+0 records in > 5275+0 records out > 2700800 bytes transferred in 26.385502 secs (102359 bytes/sec) > 3:06pm hammer:[68]> dmesg | egrep da > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 3MB (7904 512 byte sectors: 64H 32S/T 3C) > > Hmmm, how can I read more than 3MB from da0? I'll have to check to > see how fast it is w/o this change. > > Warner The problem with a taskqueue is that you are the slave to other drivers that want to do slow and expensive things in it. If someone else's taskqueue sleeps, you won't run until it wakes up. You might not see much effect of this on an unloaded system, but there certainly is lots of taskqueue code out there that is slow and heavy. Taskqueues are good for when a driver has handled the interrupt and wants to offload a heavy and/or non-time-critical function out of the fast path. They really aren't good for handling an entire driver ISR. Scott