On Tuesday 27 March 2007 3:48 pm, Pete Zaitcev wrote: > On Tue, 27 Mar 2007 13:40:23 -0700, David Brownell <[EMAIL PROTECTED]> wrote: > > > Actually, HID was one of the original motivations for using that. > > Dave Miller noticed the cost for a USB keyboard was excessive on > > (ISTR) SPARC64, and avoiding all those cache ops was a Good Thing. > > Are you sure that you're not confusing this with the DMA pool?
That's common underlying infrastructure, which was created so that the different HCDs (and by now, lots of other drivers) don't need to craft their own tools to manage DMA descriptors. > I'll poke Dave about it, thanks for the hint. > > > ISTR that isochronous transfers were discussed as potentially a > > good use of those no-cache-ops buffers. > > Hmm... A CPU has to access all that data, and reading a cache line > at a time surely as better. Although on the other hand, it's something > streaming and thus just using the cache space for no good reason. Right. "Potentially". Displacing hot cachelines for use-once data will in various cases be a lose. > > It's not clear to me that serial lines would be inappropriate; > > what guideline are you thinking of, to suggest they would be? > > I thought in terms of the exchange sitting there for extended > periods of time. This would say that HID is better to be served > uncached, and also its I/O sizes are miniscule... As far as performance > is concerned, sometimes it is cheaper to use uncached memory, for > example sunlance does it on purpose. Haven't had occasion to look at sunlance, but that's the general kind of issue. Read a few words once ... almost certainly not worth displacing *any* cache line. > In case of Oliver's patch, he fixed a bug where exchanges did not > end on a cache line boundary, so that's great. Also, the kmalloc > size was too big, so replacing a 2D matrix with a vector of pointers > was good too. His patch was correct, as far as I can tell. It just > seemed to me that in case when we do not know the benefits, we might > as well use kmalloc. Good general rule. Plus, the relevant DMA infrastructure really sucks rocks; minimum allocation size is a full page in every implementation (despite being expressed in bytes), and most of them have that nasty "can't free with irqs blocked" restriction which forces free-the-data paths to perform perverted acts ... > OK... I admit I must do something for usbmon working better when > DMA is pre-allocated, especially on PPC (where it simply gives > up immediately and returns 'D' tag). But it's somewhat difficult. > There's no portable API which I could use. That is, when the application manages DMA adressing? The driver "should" provide both the DMA and regular address, since not every underlying controller wil use the DMA address for all transfers. - Dave > > -- Pete > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
