On Sun, Sep 29, 2013 at 5:10 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 29 Sep 2013, Markus Rechberger wrote: > >> to follow up I know why it doesn't happen anymore because customers >> are using a kernel module which does optimized transfers and >> pre-allocated the URBs and transfer buffer in kernelspace, the >> interface just copies the datastream to our actual driver which sits >> in userspace. >> Goal is to get rid of that kernel module which is working around that >> allocation bug. >> >> Allan, Greg, can we add another IOCTL for telling USBFS to not use SG >> transfers (it also allocates 15k buffers and will lead to the same >> problem)? >> The old behavior was already broke, the SG transfers won't improve the >> situation in that case either. > > Then how will not using SG make the situation any better? You'll just > be back with the old, broken behavior. > I was moreover writing about mmap vs SG transfers. Basically at the moment on lower end systems SG transfers will introduce more problems than before. I guess the ioctl would not be required, I'd just allocate the memory (transfer_buffer) on driver start up, and once mmap'ed buffers are passed to the ioctl it should bypass the SG transfers. By experience I can say that on driver startup and early driver runtime I've never seen any allocation failures it only happens during runtime after some time on low end systems. There have been such discussions on regular kernel drivers too to allocate memory during boot up vs during runtime in the past. I think there was some time where >15k buffers were allowed and non SG. The experience with the chipset which stops to transfer data on latency issues made me sensitive about any change in that area. Original behavior: (Linux 2.6.32 and a few newer ones) don't allow >15k buffers (this behavior breaks at least the chipset which has those latency issues when transferring 6mb/sec only on Broadcom Chipsets). Second stage: allow >15k buffers (Linux 3.5 at least) (by increasing the transfer buffer to 50k it fixes the latency issue, the test was running for several days) Those broadcom chipsets have 1.3ghz 1GB Ram. Third stage: add SG transfers and split everything back to 15k buffers (behavior is unknown at the moment, only the STB manufacturer can provide the new kernel so I can't even test anything here the issue only came up with those Broadcom Chipsets). >> Those Sheevaplugs have 128mb memory, regular routers and NAS systems >> don't necessarily have more either. > > If you're trying to do big I/O transfers with large buffers in a highly > memory constrained system, you're already in trouble. Fiddling around > with the kernel won't help. > sure, but using the kernel module which also pre-allocates the memory has no problem at all. I searched with google, obviously no one is using USBFS/userspace USB drivers that intensive as we do because (streaming 6mb for DVB or 20mb for Analog over days) the only bug reports that come up are related to our devices and point to our forum. > In fact, you might find the best answer is to do lots of small > transfers (i.e., 8 KB or even 4 KB). > I agree, but here not only small buffers are the problem, also latency. I will send another patch version which overrides the SG transfer once a preallocated buffer is submitted. The current patch will only use the pre-allocated buffers if the buffer size is smaller than 15-16k. Markus -- 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
