On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote: > >> So what is the road from here? I guess the original questions about cache > >> coherency still apply, and that this is what I'm seeing in dmesg. > > What questions? It should be obvious that the user program should not > > touch the buffer contents while the transfer is taking place. > > The subthread I'm thinking of starts at > > http://marc.info/?l=linux-usb&m=138091207413756&w=2 > > I can't claim to have gone deeply into the details, though. Ah, okay. I don't think that's an issue. The pages don't need to be uncached because the system will flush the cache contents when the pages are mapped for DMA. That's the normal mechanism for ordinary USB transfer buffers (which are always located in cacheable memory). > > What are you seeing in dmesg? > > Several copies of > > [ 1175.838536] x86/PAT: app:2838 map pfn RAM range req uncached-minus for [mem 0x9fa4c000-0x9fa4ffff], got write-back Perhaps that will go away if you don't ask for uncached memory. > > The next step would be to massage the patch and get it into a form > > suitable for applying. This may well include changing the way the API > > works; for example, I'm not sure that allocating memory should be a > > separate step from mmap. > > Yes, it sounds a bit odd to me, too. > > I suppose there's no way to let userspace allocate this memory? Again, > for me personally it would be ideal to be able to give it in from a PBO > (ie., GPU memory). The problem with letting userspace allocate the memory is that there's no way to guarantee that the pages will lie in the first 4 GB of memory. While this doesn't matter for host controllers capable of doing 64-bit DMA, not all controllers have that capability. And you probably couldn't use GPU memory for this purpose because (I assume) the USB host controller wouldn't be able to access it via DMA. Incidentally, I wonder how well this patch really does fix your problem. What happens if you run the old program until it fails with the "unable to allocate memory" error and then try running the new program? I suspect the new program will also fail under those circumstances. The only advantage it has is that if the initial allocations succeed then you don't have to worry about later allocations failing, because the buffer memory is allocated only once. 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
