On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote: > > Interesting. I hacked libusb to get the fd. Then I did USBDEVFS_ALLOC_MEMORY, > > which succeeded (well, as soon as I filled mem.size before calling), > > then mmap on it as described (which also succeeded), and everything _works_, > > but I don't think it's actually using zerocopy, because I still see > > copy_user_enhanced_fast_string() using a lot of CPU > > (with libusb_handle_events() in the call stack). > > OK, so I did some more testing. It does actually seem to do _something_. > In particular, memset_erms() all but disappeared from my profile, which was > stated in the thread as one advantage of the patch. > > I ran overnight for eight hours (one card, continuous stream at about > 900 Mbit/sec, 128 kB buffers) and it didn't get any page allocation features. > Before the patch, it was unlikely but not impossible to run for that long. > I've kept it running, but it's weak evidence of solving the problem. > > As for general performance, I'm unsure; from a quick glance at perf, I _may_ > have more L3 misses when reading the data back in userspace, but I won't say > anything for sure here without a closer look. > > So, in general I think it's good news, although I don't fully understand why > I still need the kernel-to-userspace copy for isochronous transfer. Maybe you can add some debugging to copy_user_enhanced_fast_string(). Add a flag, and call dump_stack() in that routine if the flag is set. Then set and clear this flag at the appropriate spots in devio.c. 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
