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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
