From owner-freebsd-current@FreeBSD.ORG Fri Nov 12 23:17:42 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 2A31616A4CE for ; Fri, 12 Nov 2004 23:17:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A327743D45 for ; Fri, 12 Nov 2004 23:17:41 +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 iACNJPhZ006562; Fri, 12 Nov 2004 16:19:25 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <419544C7.5030104@freebsd.org> Date: Fri, 12 Nov 2004 16:18:31 -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: Stephan Uphoff References: <41952FBD.40602@freebsd.org> <20041112.150905.105578119.imp@bsdimp.com> <419536C0.5040807@freebsd.org> <20041112.152144.55301158.imp@bsdimp.com> <1100301093.85991.72.camel@palm.tree.com> In-Reply-To: <1100301093.85991.72.camel@palm.tree.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 cc: "M. Warner Losh" 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:17:42 -0000 Stephan Uphoff wrote: > 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 > I've actually been testing with this line turned off for quite a while. It no longer makes a difference for stability. Scott