On Mon, 30 Sep 2013, Markus Rechberger wrote: > to explain why Isochronous makes such a difference, the kernel driver > doesn't do the memset anymore for each urb packet. > However that patch addresses multiple issues > * Isochronous improvement by removing memset for each packet > * Pre-Allocation to prevent allocation failures during runtime. > * Allow to restore the original behavior for >15k buffers (I'd Why do you use 15 KB as the boundary line? Wouldn't it make more sense to use 16 KB (that is, four pages)? > recommend to make further decisions about forcing SG transfers over > Bulk transfers once manufacturers deliver low-end devices which > include both possibilities) here we have seen the latency issue with > certain chipsets when buffers are too small I don't know the > behavior/latency of SG transfers unfortunately and there's no way to > test it on the particular target system - other systems do not trigger > that problem. In general, an SG transfer has slightly higher time and memory requirements than a non-SG transfer. It's not a big difference. But with non-SG, the memory is allocated as a single, big buffer, whereas with SG the memory is allocated as a bunch of smaller buffers. Therefore, when memory is fragmented (which will happen on a system with a small amount of memory), SG transfers are more likely to succeed than non-SG. For example, you are more likely to be able to allocate eight 16-KB memory regions (SG) than a single 128-KB region (non-SG). > As far as I can see there's still some space for improvements. (eg. > pre-allocate large buffers (15k) for USB 3.x otherwise it will end up > with allocation failures during runtime on low-end systems - as seen > by our customers with USB 2.0 and 15k buffers on low-end systems). > With SG and USB 3.0 this problem should happen even quicker than with USB 2.0. Why would low-end systems be using USB-3? 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
