Date: Mon, 15 Nov 2004 00:31:20 -0800 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Scott Long <scottl@freebsd.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: usb with fast interrupts Message-ID: <20041115083120.GI57546@funkthat.com> In-Reply-To: <41986351.2070806@freebsd.org> References: <20041112.143439.33211003.imp@bsdimp.com> <41952FBD.40602@freebsd.org> <20041115080155.GH57546@funkthat.com> <41986351.2070806@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote this message on Mon, Nov 15, 2004 at 01:05 -0700:
> John-Mark Gurney wrote:
> >Scott Long wrote this message on Fri, Nov 12, 2004 at 14:48 -0700:
> >
> >>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.
> >>
> >>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?
> >
> >
> >If you need low latency, I made taskqueue's easier to create:
> >TASKQUEUE_DEFINE_THREAD(kqueue);
> >
> >and then use:
> > taskqueue_enqueue(taskqueue_kqueue, &kq->kq_task);
> >
> >of course replace kqueue w/ your own string... Check the taskqueue(9)
> >man page for more details.
> >
>
> So the only problem with TASKQUEUE_DEFINE_THREAD() is that it appears
> impossible at the moment to clean up the thread that this creates when
> the driver wants to unload.
That shouldn't be too hard to fix. :)
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041115083120.GI57546>