Greg, Oliver, can you justify why 190K is acceptable for Isochronous (which has been in the kernel for a long long time now) but less than 50k is suddenly not acceptable for bulk when using USBFS? Especially while the wild out there already approved that 190K is okay even on embedded systems? That's the only thing I would like to know :-) We made many tests here (and have many more customers using Isoc 190k buffers) and memory allocation has a much better performance instead of pushing ioctls forward/backward for reading those small packets. I do understand your concern but from my point and experience with it (we've been using it for 3 years so far) it does not cause any problem. We reached the 1k amount of users using 190k Isoc buffers a long time ago, those are pushing 170 Mbit a second. The bulk purpose is for 80mbit a second only. I would just like to have all supported modes with performance and not too many changes. Currently we only get good performance with isochronous, bulk USBFS performance could just be better with Linux, our software works well enough with Mac, Solaris and FreeBSD with Bulk and Iso. BR, Markus On Fri, Aug 19, 2011 at 12:45 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On Fri, Aug 19, 2011 at 8:23 AM, Oliver Neukum <oliver@xxxxxxxxxx> wrote: >> Am Mittwoch, 17. August 2011, 19:44:16 schrieb Markus Rechberger: >>> I understand that USBFS is not 100% optimized, although we are already >>> using 3-4 times that much buffer with isochronous and it was working >>> fine for years so far as long as the system doesn't run out of memory >>> .. but even kerneldrivers would have issues with it in such a >>> situation. >> >> The problem is not what happens on your test system dedicated to this use. >> There it'll work. But you allowed everybody else to make the kernel request >> the second largest chunk of memory there is. On a otherwise busy system >> with fragmented memory this is not good. >> >> As I said, you want scatter/gather if you need this. >> There still would be the problem with the API, but if this is really a problem, >> you could define a new ioctl() >> > > let's say there are a few thousand users of the 190k isochronous implementation. > I don't want to add more complex code to the kernel, if it's not > accepted I'm okay with it, > since I know the performance impact I can recommend it to those who > are interested in it. > Our software works without it anyway, and Bulk is just for special use > in our case. > > Best Regards, > 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
