On Sat, Oct 5, 2013 at 4:34 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 4 Oct 2013, Markus Rechberger wrote: >> >> I was only testing reading the data so I didn't see any caching >> effects since I don't have a device or driver which I can send a lot >> data out. >> As far as I understand pgprot_noncached would only be required when >> sending data (writing data to the DMA'able buffer). No, applciation still may read obsolete data from the mapped buffer even after transfer from device is complete without any synchronization. >> >> This question is still open. > > The buffer should be cached. The userspace program will have to make > sure that it doesn't try to access the buffer while DMA is in progress. > As long as that restriction is obeyed, the USB core will take care of > mapping the buffer for DMA (which flushes the cache). No, HCD mapping/unmapping can't deal with the problem since they use the kernel direct-mapped virtual address of the buffer to flush cache, but applications use the mapped virtual address, and CPU can use both the two virtual addresse to cache data, so it is probable that the transfer buffer can be cached in more than one locations by CPU for VIVT or VIPT-alias cache. So Markus takes the simplest way which uses nocahced mapping, but it may degrade performance on some ARCHs since it is reported that it is extremely slow to access non-cached memory on some ARMv7 SoCs. > >> > As I understand it, you wrote this in order to solve problems where >> > memory couldn't be allocated for USB transfers. If the system is >> > running short on memory, won't your USBDEVFS_ALLOC_MEMORY ioctl also >> > fail? >> > >> >> No, the buffers will be kept in a list and re-used (aside of that they >> are also kept in a list in devio.c and re-used). When the buffers are >> allocated initially there's no chance to fail this process during >> run-time. > > Why not? What if the memory is already almost full? The call to > alloc_pages_exact() could fail. > > I agree this is less likely than a failure with the current system, but > it is still possible. With CONFIG_COMPACTION enabled, it is hard to trigger the allocation failure, and actually on some ARCHs, size of kernel stack or page directory table for creating each process is 16KB. Thanks, -- Ming Lei -- 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
