From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 23:11:36 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 7BC1B16A4CE for ; Fri, 12 Nov 2004 23:11:36 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id E6E6B43D3F for ; Fri, 12 Nov 2004 23:11:35 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 3191 invoked by uid 89); 12 Nov 2004 23:11:35 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 12 Nov 2004 23:11:35 -0000 Received: (qmail 3156 invoked by uid 89); 12 Nov 2004 23:11:34 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 12 Nov 2004 23:11:34 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id iACNBX5R086324; Fri, 12 Nov 2004 18:11:33 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: "M. Warner Losh" In-Reply-To: <20041112.152144.55301158.imp@bsdimp.com> References: <41952FBD.40602@freebsd.org> <419536C0.5040807@freebsd.org> <20041112.152144.55301158.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1100301093.85991.72.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 12 Nov 2004 18:11:33 -0500 Content-Transfer-Encoding: 7bit cc: scottl@freebsd.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 23:11:36 -0000 On Fri, 2004-11-12 at 17:21, M. Warner Losh wrote: > In message: <419536C0.5040807@freebsd.org> > Scott Long writes: > : 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. > > In this case we have handled the time critical part of the ISR. It > acks things and then queues the 'slow' stuff, which is basically > everything. On Open/NetBSD this part of the code already runs in a > SWI. The point about sharing the taskqueue with other drivers is a > valid one that I'd not considered... > > Warner If you are running i386 with PREEMPTION you may want to try this patch: Index: intr_machdep.c =================================================================== RCS file: /cvsroot/src/sys/i386/i386/intr_machdep.c,v retrieving revision 1.11 diff -u -r1.11 intr_machdep.c --- intr_machdep.c 3 Nov 2004 18:03:06 -0000 1.11 +++ intr_machdep.c 11 Nov 2004 22:31:19 -0000 @@ -205,7 +205,9 @@ isrc->is_pic->pic_eoi_source(isrc); error = 0; /* XXX */ +#if 0 td->td_pflags &= ~TDP_OWEPREEMPT; +#endif critical_exit(); } else { /* Otherwise preemption to SWI is disabled if triggered by a fast interrupt. On a busy system it may take a while until until the SWI is serviced (Longer than without PREEMPTION!) jhb@ agrees that the line "td->td_pflags &= ~TDP_OWEPREEMPT;" is no longer needed. The patch just needs more testing and I don't have hardware that really stresses fast interrupts. ( No I am NOT setting up a serial PPP connection for testing purposes!) Stephan