On Friday 22 April 2005 5:06 am, Oliver Neukum wrote:
> Am Donnerstag, 21. April 2005 22:23 schrieb David Brownell:
> > The main place I use tasklets, rather than a work queue, is in
> > "usbnet" as leftover from some 2.4 code that was coping with the
> > fact that neither of the UHCI drivers behav
Am Donnerstag, 21. April 2005 22:23 schrieb David Brownell:
> The main place I use tasklets, rather than a work queue, is in
> "usbnet" as leftover from some 2.4 code that was coping with the
> fact that neither of the UHCI drivers behaved well when completion
> handlers did certain things; as in,
On Monday 18 April 2005 2:37 pm, Alan Stern wrote:
> On Mon, 18 Apr 2005, Oliver Neukum wrote:
>
> > > > Their own fault. Drivers can do any number of stupid things with
> > > > interrupts
> > > > disabled.
> > >
> > > Well sure, but that doesn't help. It's part of the API, it's necessary if
>
On Mon, 18 Apr 2005, Oliver Neukum wrote:
> > > Their own fault. Drivers can do any number of stupid things with
> > > interrupts
> > > disabled.
> >
> > Well sure, but that doesn't help. It's part of the API, it's necessary if
>
> Is it necessary or is it part of the API? If the latter, then
Am Montag, 18. April 2005 17:34 schrieb Alan Stern:
> > > Furthermore, there's nothing to prevent USB device drivers from calling
> > > usb_submit_urb() or usb_unlink_urb() while they have disabled interrupts
> > > for their own reasons. That's a perfectly legal thing to do, but again it
> > > mea
On Mon, 18 Apr 2005, Oliver Neukum wrote:
> As calling the completion handler is the latest major operation in handling
> an interrupt, it seems to me that you've already broken the guarantee
> that there will be no intervening interrupts, if you have used any tasklet
> in between.
There is no su
On Mon, 18 Apr 2005, Oliver Neukum wrote:
> > Yes, this was a usb-storage measurement. That's the only sort of
> > devices I have that make serious demands on the HCD. And this _was_
> > supposed to be a worst-case measurement, after all.
>
> The worst case for latency? Then you should measur
On Sun, 17 Apr 2005, David Brownell wrote:
> Or other IRQs, etc. I punted the detailed analysis, but briefly:
>
> * OHCI typically gets a completion (WDH) IRQ at the start of a frame,
> then if there's anything on the control or bulk queues it'll do
> that for 10% of a frame and then s
Am Montag, 18. April 2005 04:24 schrieb Alan Stern:
> On Sun, 17 Apr 2005, Oliver Neukum wrote:
>
> > > Using spin_lock_bh() in enqueue or dequeue isn't a solution because
> > > existing code already calls these routines with interrupts disabled.
> >
> > How so? If you convert the irq code to a
Am Montag, 18. April 2005 04:37 schrieb Alan Stern:
> On Sun, 17 Apr 2005, David Brownell wrote:
>
> > So basically this was a usb-storage measurement. That's probably a
> > worst-case from the HCD perspective, since virtually everything else
> > only uses very short queues. (Other than "usbnet"
On Sunday 17 April 2005 8:09 pm, Alan Stern wrote:
> On Sun, 17 Apr 2005, David Brownell wrote:
>
> > I just had a thought: maybe one of the reasons Microsoft has such big
> > per-request latencies is that they're using something analgous to tasklets.
> > It's always puzzled me why they go to suc
On Sun, 17 Apr 2005, David Brownell wrote:
> > I sense a common theme in these comments! You're clearly concerned about
> > undue delays during submission.
>
> Among other things. As I've pointed out, (non-PIO) HCDs basically do
> only two things: they package URBs for HC DMA hardware, then t
On Sun, 17 Apr 2005, David Brownell wrote:
> So basically this was a usb-storage measurement. That's probably a
> worst-case from the HCD perspective, since virtually everything else
> only uses very short queues. (Other than "usbnet", which at full
> speed uses shorter queue lengths; or usb aud
On Sun, 17 Apr 2005, Oliver Neukum wrote:
> > Using spin_lock_bh() in enqueue or dequeue isn't a solution because
> > existing code already calls these routines with interrupts disabled.
>
> How so? If you convert the irq code to a tasklet, it'll run in a tasklet.
Yes it will. But it will stil
On Wednesday 13 April 2005 3:08 pm, Alan Stern wrote:
> On Wed, 13 Apr 2005, David Brownell wrote:
>
> > A tasklet for the IRQ handling code wouldn't bother me the way even
> > the concept of one in the submit path does!
>
> I sense a common theme in these comments! You're clearly concerned abou
On Friday 15 April 2005 1:58 pm, Alan Stern wrote:
> On Fri, 15 Apr 2005, David Brownell wrote:
> >
> > Could you summarize what tools you used to generate those numbers?
> > Like what kind of driver(s) were active, with what kind of loads.
> > Audio? Storage? Networking? How about other statis
> > True, but relvant only for irq handlers.
>
> So you agree that it might make sense to move uhci_irq to a tasklet, since
> it _is_ an IRQ handler?
Absolutely. Sorry about being unclear about that.
[..]
> >From the point of view of enqueue, the other code is dequeue and uhci_irq.
> >From t
On Sun, 17 Apr 2005, Oliver Neukum wrote:
> > A tasklet can be useful for another reason. Consider that even if an IRQ
> > handler does run with interrupts enabled, its own IRQ line still has to
> > remain disabled. So any devices sharing the IRQ line are unable to
> > interrupt the CPU until th
Am Sonntag, 17. April 2005 04:52 schrieb Alan Stern:
> On Sat, 16 Apr 2005, Oliver Neukum wrote:
>
> > A tasklet is useful only if you cannot enable interrupts because you are
> > in hard irq context.
>
> A tasklet can be useful for another reason. Consider that even if an IRQ
> handler does run
On Sat, 16 Apr 2005, Oliver Neukum wrote:
> A tasklet is useful only if you cannot enable interrupts because you are
> in hard irq context.
A tasklet can be useful for another reason. Consider that even if an IRQ
handler does run with interrupts enabled, its own IRQ line still has to
remain disa
On Saturday 16 April 2005 12:31 pm, Oliver Neukum wrote:
>
> > > What is the point of using a tasklet? It is about locking, not context.
> >
> > No! Just the reverse. The point of using a tasklet has nothing to do
> > with locking. It is about running time-consuming code in an
> > interrupt-en
> > What is the point of using a tasklet? It is about locking, not context.
>
> No! Just the reverse. The point of using a tasklet has nothing to do
> with locking. It is about running time-consuming code in an
> interrupt-enabled context. That's why bottom halves were invented in the
> first
On Sat, 16 Apr 2005, Oliver Neukum wrote:
> > > But the enqueue times are worse, so are in more need of optimisation.
> >
> > Although enqueue took more time than IRQ handling on average, I'm more
> > concerned about maximum times. Enqueue's maximum time was worse on one of
> > the computers, IR
Am Samstag, 16. April 2005 04:47 schrieb Alan Stern:
> On Sat, 16 Apr 2005, Oliver Neukum wrote:
>
> > > The point is not whether things are interrupt-driven, it's whether or not
> > > interrupts are enabled. In a bottom-half handler all the time-consuming
> > > work can be done with interrupts
> > Interesting that this has twice as much many IRQs as URBs, and
> > that the P4 times for enqueue are disproportionately better.
> > Cache effects, maybe?
>
> I don't know the answer to either question, although it should be possible
> to find out why there are so many more IRQs than URBs.
Af
On Sat, 16 Apr 2005, Oliver Neukum wrote:
> > The point is not whether things are interrupt-driven, it's whether or not
> > interrupts are enabled. In a bottom-half handler all the time-consuming
> > work can be done with interrupts enabled.
>
> How so? Part of the work done in IRQ can be shif
On Fri, 15 Apr 2005, David Brownell wrote:
> > > > Auditing locking in all drivers is not.
> > > > Switching to tasklets would result in revisting locking in drivers.
> > >
> > > Why would switching uhci-hcd over to a tasklet require any change in
> > > other
> > > drivers?
> >
> > You have t
On Friday 15 April 2005 4:08 pm, Oliver Neukum wrote:
> Am Samstag, 16. April 2005 00:53 schrieb David Brownell:
> > > > > Auditing locking in all drivers is not.
> > > > > Switching to tasklets would result in revisting locking in drivers.
> > > >
> > > > Why would switching uhci-hcd over to a t
Am Samstag, 16. April 2005 00:53 schrieb David Brownell:
> > > > Auditing locking in all drivers is not.
> > > > Switching to tasklets would result in revisting locking in drivers.
> > >
> > > Why would switching uhci-hcd over to a tasklet require any change in
> > > other
> > > drivers?
> >
>
Am Freitag, 15. April 2005 22:58 schrieb Alan Stern:
> > > > It's true that other changes I have planned for the driver will reduce
> > > > these values, although it's impossible to predict by how much. However
> > > > I
> > > > think this gives a pretty good indication that splitting the drive
> > > > usb_urb_alloc(usb_host_endpoint *ep, // hook to HCD
> > > > size_t maxbuf, // ... for prealloc of N TDs
> > > > unsigned n_iso,
> > > > unsigned gfp_flags);
> > > >
> > >
> > > It is pretty straightforward a change.
Maybe. That
Am Freitag, 15. April 2005 22:59 schrieb Alan Stern:
> On Fri, 15 Apr 2005, Oliver Neukum wrote:
>
> > Am Freitag, 15. April 2005 19:38 schrieb David Brownell:
> > > > IMHO the best way to reduce times is to move all memory
> > > > allocations into urb allocation.
> > >
> > > That's an approach
On Fri, 15 Apr 2005, Oliver Neukum wrote:
> Am Freitag, 15. April 2005 19:38 schrieb David Brownell:
> > > IMHO the best way to reduce times is to move all memory
> > > allocations into urb allocation.
> >
> > That's an approach I've thought about. Unfortunately it's costs an invasive
> > API c
On Fri, 15 Apr 2005, David Brownell wrote:
> On Friday 15 April 2005 9:45 am, Oliver Neukum wrote:
> > Am Freitag, 15. April 2005 17:13 schrieb Alan Stern:
> > >
> > > The two main places where the driver disables interrupts for long periods
> > > are in the enqueue routine and the IRQ handler.
Am Freitag, 15. April 2005 19:38 schrieb David Brownell:
> > IMHO the best way to reduce times is to move all memory
> > allocations into urb allocation.
>
> That's an approach I've thought about. Unfortunately it's costs an invasive
> API change: passing the device (or better yet, usb_host_end
On Friday 15 April 2005 9:45 am, Oliver Neukum wrote:
> Am Freitag, 15. April 2005 17:13 schrieb Alan Stern:
> >
> > The two main places where the driver disables interrupts for long periods
> > are in the enqueue routine and the IRQ handler.
Well, that's where most of the time gets spent regard
Am Freitag, 15. April 2005 17:13 schrieb Alan Stern:
> On Wed, 13 Apr 2005, David Brownell wrote:
>
> > > That was the main motivation, although I'd had this in the back of my
> > > mind
> > > for a long time. Yes, it would be nice to see some real numbers for
> > > those
> > > latencies. I
On Wed, 13 Apr 2005, David Brownell wrote:
> > That was the main motivation, although I'd had this in the back of my mind
> > for a long time. Yes, it would be nice to see some real numbers for those
> > latencies. I suppose I could add some high-precision timer stuff to the
> > driver, to se
On Wed, 13 Apr 2005, David Brownell wrote:
> That doesn't describe the submit paths at all (linking things into
> the schedule) ... and doesn't describe the relevant bits of the unlink
> paths either (unlinking them from the schedule, at least from the
> host perspective; the HC will agree later).
On Monday 11 April 2005 8:25 pm, Alan Stern wrote:
> On Mon, 11 Apr 2005, David Brownell wrote:
>
> > > Actually this is a new issue, not a lurking one. The whole point of that
> > > patch was because I'm going to make the majority of the UHCI driver run in
> > > a bottom half (a tasklet). This
On Mon, 11 Apr 2005, David Brownell wrote:
> > Actually this is a new issue, not a lurking one. The whole point of that
> > patch was because I'm going to make the majority of the UHCI driver run in
> > a bottom half (a tasklet). This includes most of the work involved in
> > submitting and unli
On Monday 11 April 2005 2:26 pm, Alan Stern wrote:
> On Mon, 11 Apr 2005, David Brownell wrote:
>
> > > That's just it. The first part applies only when an URB completes with a
> > > hardware error, _not_ an unlink or kill!
> >
> > It was intended to cover _all_ fault reports. Unlink/kill is j
On Mon, 11 Apr 2005, David Brownell wrote:
> > That's just it. The first part applies only when an URB completes with a
> > hardware error, _not_ an unlink or kill!
>
> It was intended to cover _all_ fault reports. Unlink/kill is just
> a software-induced fault.
Alright. I'll send an update
On Monday 11 April 2005 1:13 pm, Oliver Neukum wrote:
> Am Montag, 11. April 2005 21:07 schrieb Alan Stern:
> > That's just it. The first part applies only when an URB completes with a
> > hardware error, _not_ an unlink or kill! Do you think this needs to be
> > made more clear? The second part
On Monday 11 April 2005 12:07 pm, Alan Stern wrote:
> On Mon, 11 Apr 2005, David Brownell wrote:
>
> > > * Host Controller Drivers (HCDs) place all the URBs for a particular
> > > * endpoint in a queue. Normally the queue advances as the controller
> > > ...
> > > + * hardware processes each
Am Montag, 11. April 2005 21:07 schrieb Alan Stern:
> That's just it. The first part applies only when an URB completes with a
> hardware error, _not_ an unlink or kill! Do you think this needs to be
> made more clear? The second part applies when an URB terminates because
Yes, you should make
On Mon, 11 Apr 2005, David Brownell wrote:
> Just for the record -- this doesn't look like a change at all, but
> I'm not sure it catches the nuances correctly either.
It is a change, but if that wasn't clear to you then perhaps the wording
needs to be improved.
> On Tuesday 05 April 2005 8:55
Just for the record -- this doesn't look like a change at all, but
I'm not sure it catches the nuances correctly either.
On Tuesday 05 April 2005 8:55 am, Alan Stern wrote:
> @@ -420,12 +420,16 @@
> *
> * Host Controller Drivers (HCDs) place all the URBs for a particular
> * endpoint in a q
Greg & David:
In response to complaints about excessive latency in the uhci-hcd driver
I'm planning to convert it to a top-half/bottom-half design. It turns out
that to do this, the USB API has to be modified slightly since the driver
will not be able to meet one of the guarantees in the current
49 matches
Mail list logo
