> How about a different radical approach. Remembering that there's > already a queue of URBs in the HCD glue, it's clear that they don't > all need to have TDs immediately allocated ... when an endpoint queue > is "empty enough", the lower level HCD code could check for urbs > that are queued to that endpoint but which don't yet have TDs, then > allocate (and queue) TDs for those URBs.
Hi Dave, I agree 100%. > That notion could be combined with the notion of TD queues that > are throttled in the same way many network drivers throttle. For > example, maybe a bulk endpoint would have no more than 40 TDs > at a given moment ... that's enough to keep the controller busy > for about two frames. Whenever a set of TDs completes from the > front of the td list, they could be recycled to advance transfers > starting from end of that td list. (Implies recycling TDs as > the HC returns them, instead of when the HCD returns urbs.) > > > One of the key differences between UHCI and EHCI (or OHCI) is > that only UHCI uses packet-at-a-time TDs. Which means that a > given request is going to need many more TDs. It seems to me > that strategies to limit TD usage (like those two) would be > particularly beneficial with UHCI. > > > Allocation and freeing of TD's isn't as much of a problem as you > > seem to think. Although shrinking them certainly won't hurt, they are > > taken from a pre-allocated pool of DMA-coherent memory. Allocation and > > freeing are thus extremely quick. > > They're not necessarily pre-allocated; the pool size will grow in some > cases (doesn't currently shrink). But with UHCI the pool can grow to > be quite huge ... and most of those TDS are sitting idle most of the > time. While desktop machines may not have particular problems running > short of memory, that's not always true. The volume of TDs can be a > problem even if allocating the next one isn't. Exactly. Here is an oprofile for a machine doing heavy ssh traffic and nothing else. Should uhci_hcd really be so present? ... 4733 0.8435 0.0000 /usbcore 5769 1.0281 0.0000 /speedtch 8838 1.5751 0.0000 /crc32 47991 8.5529 0.0000 /uhci_hcd 102476 18.2632 0.0000 /home/duncan/bollux-2.5/vmlinux 173831 30.9801 0.0000 /usr/bin/ssh 213933 38.1271 0.0000 /usr/lib/i686/cmov/libcrypto.so.0.9.7 Duncan. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
