On Wed, Nov 25, 2015 at 7:19 PM, Steinar H. Gunderson <se...@google.com> wrote: > Add a new interface for userspace to preallocate memory that can be > used with usbfs. This gives two primary benefits:
I got this when trying to allocate a little bit large buffer (~4MB) using the new userspace libusb_dev_mem_alloc(): > [ 1706.212407] usb 2-1.1: reset SuperSpeed USB device number 3 using xhci_hcd > [ 1706.234823] xhci_hcd 0000:00:14.0: swiotlb buffer is full (sz: 4325376 > bytes) > [ 1706.234827] swiotlb: coherent allocation failed for device 0000:00:14.0 > size=4325376 > [ 1706.234830] CPU: 1 PID: 3233 Comm: Protonect Tainted: G U W > 4.4.0-rc8-amd64 #1 Debian 4.4~rc8-1~exp1 > [ 1706.234831] Hardware name: LENOVO 20ALCTO1WW/20ALCTO1WW, BIOS GIET76WW > (2.26 ) 08/27/2014 > [ 1706.234833] 0000000000000000 000000000f50c266 ffffffff812e6019 > ffffffffffffffff > [ 1706.234836] ffffffff8130dc45 ffff88020000000b 0000000000420000 > ffffffff81a2a0e0 > [ 1706.234838] ffff880206263d80 0000000000000000 ffff88021c892f40 > 0000000000420040 > [ 1706.234841] Call Trace: > [ 1706.234847] [<ffffffff812e6019>] ? dump_stack+0x40/0x57 > [ 1706.234851] [<ffffffff8130dc45>] ? swiotlb_alloc_coherent+0x135/0x150 > [ 1706.234867] [<ffffffffa021deb1>] ? hcd_buffer_alloc+0xb1/0x130 [usbcore] > [ 1706.234875] [<ffffffffa0221ab5>] ? usbdev_mmap+0xa5/0x1b0 [usbcore] > [ 1706.234880] [<ffffffff813bbc25>] ? > tty_insert_flip_string_fixed_flag+0x85/0xe0 > [ 1706.234885] [<ffffffff8119af87>] ? mmap_region+0x3e7/0x660 > [ 1706.234888] [<ffffffff8119b536>] ? do_mmap+0x336/0x420 > [ 1706.234892] [<ffffffff8118213f>] ? vm_mmap_pgoff+0xaf/0xf0 > [ 1706.234895] [<ffffffff811999dd>] ? SyS_mmap_pgoff+0x1ad/0x270 > [ 1706.234898] [<ffffffff811d53b6>] ? SyS_write+0x76/0xc0 > [ 1706.234903] [<ffffffff815829f2>] ? system_call_fast_compare_end+0xc/0x67 I understand there are some requirements on the allocation such that large blocks are not always available. But what is the proper way to determine the upper limit of the size such that the user can avoid generating warnings like this? (Also, the application really wants to be able to allocate large buffers, maybe tune swiotlb=?.) Test results: Basic testing with smaller buffer size shows the patch works well with Kinect v2 (~260MB/s isochronous). Tests were performed on top of 4.4-rc8 with Debian config. I'm still trying to verify whether this patch fixes page allocation failure, but is having some trouble reproducing memory fragmentation. I will later test it on the original machine which had the problem. Regards, Lingzhu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
