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 audio, which usually keeps > only two ISO transfers of a handful of msec each.) Only usb-storage > is routinely queueing more than a dozen KBytes or so (at full speed).
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. > > (A lot of kernel debugging features, like cache poisoning, were turned on > > since that's how I normally do my development. They may have had a > > significant impact.) > > Cache/memory poisoning certainly would; I've seen it. Of course, I > normally leave that on too! Though thankfully it's been ages since > I've had to chase a bug where an HC was using memory after it was freed > by an HCD. Remember back a few years when that was sadly common? :) Most of that must have been cleared up before I began working seriously on HCD development -- or else my memory isn't what it used to be. Only one example comes to mind... It would indeed be worthwhile comparing the test results with and without cache poisoning. > > Would you like to see my test code? I'll send it to you off-list if you > > want -- not because it's big but because it's so ugly. It should be easy > > enough to adapt it to OHCI and EHCI. > > Sure, please do. It'd be worth gathering statistics at the usbcore > level, IMO, for numbers that are directly comparable. Perhaps so, but that won't tell you exactly how much time the HCD spends with interrupts disabled. > > I'm not sure what would be the best/easiest approach. Preallocating TDs > > may not be good if the URB is going to live for a long time. > > It'd be "good" in the sense of "when that URB is used, it'll have TDs > available". The "not good" would be limited to memory from that dma_pool > not being easily shared ... a non-issue unless urbs sit idle. That's what I was concerned about. I think a lot of URBs do sit idle, although maybe not a lot that have large transfer lengths. Note that usb-storage uses one single URB for each device that it manages, and the URB lives as long as the device is attached, whether in use or not. > With memory/cache poisoning, allocating and freeing each write whole TDs. > So the cost to allocate a new one from a dma_pool will be more than the > cost to initialize one with data (since it's got to find a TD to allocate). > > Ergo my observation that a freelist would be quicker. It can also be used > to prioritize allocation to TDs that are already cache-hot. Using a freelist is a good idea, and I'll implement it when I get around to making those changes. > > This is one of those changes I mentioned earlier. It shouldn't be > > necessary to have more than, say, 500 TDs allocated for an endpoint at any > > time. That's about 26 ms worth, or 31 KB of data. So long as a > > completion interrupt is issued every 200 TDs, it should work fine. > > I think this approach is the one I'd take if I had time to do that kind > of work. I suspect it'd be a much bigger win with UHCI though! Most certainly! Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
