usb with fast interrupts
Scott Long
scottl at freebsd.org
Fri Nov 12 15:17:42 PST 2004
Stephan Uphoff wrote:
> On Fri, 2004-11-12 at 17:21, M. Warner Losh wrote:
>
>>In message: <419536C0.5040807 at freebsd.org>
>> Scott Long <scottl at freebsd.org> writes:
>>: M. Warner Losh wrote:
>>: > In message: <41952FBD.40602 at freebsd.org>
>>: > Scott Long <scottl at freebsd.org> 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: <Sony MSC-U04 3.00> 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
More information about the freebsd-current
mailing list