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. 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. /* Steinar */ -- Homepage: https://www.sesse.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html