On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 28 Sep 2013, Markus Rechberger wrote: > >> >> My next step would be to eliminate the kmallocs/kfrees for the single >> >> urbs (just by allocating the urbs with the same mechanism and passing >> >> the returned pointer to SUBMIT_URB). >> > >> > The time spent allocating and freeing URBs is probably pretty small. >> > >> >> pre-allocating should at least solve those issues: >> http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 > > As far as I can tell, that bug report isn't related to URB allocation. > It looks like the failure occurred when allocating memory for the > transfer buffer, not when allocating memory for the URB. That's what I mean, URB pre-allocation would just be for having it complete (the same is available on MacOSX), if it's not wanted I don't mind either. At the time the bugreport was made in our forum we were allocating around 15k buffers, it happened during runtime so it worked for some time and then stopped with those allocation problems. I hope the SG transfer does not introduce any latency issues we have some usb chipsets which are very picky about latency issues on embedded systems. We got it work by tuning the transfer size, if the timings are not met the device will just disable the transfer. Unfortunately it will take a second to detect that by the driver and re-enabling the transfer which means that it will corrupt the data. I do not have a good feeling about pushing SG transfers into the kernel by modifying the legacy mode without having any experience with it. While the idea behind SG transfers is definitely ok but who knows how it will perform with such devices. >> but now when looking closer SG support can disable the support for >> shared memory support for bulk transfers. > > I don't know what you're talking about. What has shared memory got to > do with SG or anything else we are discussing? > sorry I probably picked the wrong words for that. >> It should be possible to turn off SG Support in favor of >> pre-allocating the buffers (or preallocate the buffers for SG). > > Only if the buffer can be allocated as a single contiguous region of > memory, in which case SG wouldn't be needed anyway. > >> This problem happened several times on Sheevaplug ARM systems from Marvell. > > I don't see what difference the platform or architecture would make. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
