On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 11:24:39AM -0500, Alan Stern wrote: > >> What exactly am I looking for, beyond the stack trace the kernel already > >> gives me? > > Find out where copy_user_enhanced_fast_string is being called from, and > > using that information, figure out why it was called. That will tell > > you why this approach isn't yielding true zerocopy performance. > > The stack trace is simple enough, although I fear there's some inlining going > on: > > - 9,50% 9,50% app [kernel.kallsyms] [k] copy_user_enhanced_fast_string > - copy_user_enhanced_fast_string > - 9,45% __GI___ioctl > - 9,30% op_handle_events > handle_events > libusb_handle_events_timeout_completed > libusb_handle_events > BMUSBCapture::usb_thread_func > execute_native_thread_routine > > I'm not honestly sure if the patch even tries to do zerocopy for isochronous > (it might be bulk only), but I'll try to understand what's going on. The routine to look at is copy_urb_data_to_user() in devio.c. As far as I can see, the patch doesn't touch it. That's undoubtedly where all the waste is coming from. The routine shouldn't do anything if the data buffer was mmap'ed. > For the better news: My program ran for eight hours more without hitting the > page allocation failures. So I suppose the patch (with cooperation from user > space, of course) really solves the immediate problem. That's good news. 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
