Documentation/cachetlb.txt describes Cache and TLB Flushing. I had implemented functions for SuperH, and have hacked for M32R. I think that this documentation is basically for architecture maintainers. It would be better for file systems developers and device drivers maintainers to know about the cache alias issues too. Hacking for KUROBOX/PRO which uses ARM9 variant, I have encountered a question for this API and cache alias issue. I need a clarification about this API from the view point of device drivers. Please help me. I'm sending this message to linux-arch, because architecture maintainers know well about this API. I think that device drivers have to care about following two things: (1) cache coherency wrt DMA (2) cache alias between kernel access and user access Handling of (1) sometimes also means (2) automatically, but we have (2)-only cases too. When a device driver accesses memory, and it will be mapped to user space, there is a possibility of cache alias (index of cache will be different between kernel access and user access). In this case, the driver should call flush_dcache_page(), I think. Let me take an example of drivers/scsi/gdht.c (Intel/ICP RAID Controller support), I am reading linux-2.6.24-rc3. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/scsi/gdth.c;h=b253b8c718d362e3215e2520e6a7eb576296474b;hb=HEAD#l2357 At the function gdth_copy_internal_data(), which does scatter-gather, it calls kmap_atomic to get the kernel address of the page, and does memcpy. Then, it calls flush_dcache_page() here, because we know it may results cache alias between user space. (And then, kunmap follows...) I think that this code is right. Middle layers (block I/O, file system, or page cache handling) cannot guess possible cache alias by device drivers correctly because there are two possibilities: (a) It does DMA access and CPU does not touch memory, and data will be on memory correctly. In this case, no cache alias issues between kernel access and user access. (b) Device drivers touchs memory by itself (such as scatter-gether). In this case, cache alias issues may occur. It is device driver who knows well about its memory access, not middle layers. So I think that it would be better to ask device drivers maintainers to handle the cache alias issues there, if we care performance. But I also think that it would be too much request to device drivers... For better code, I believe that this is device drivers' responsibility. How do you think? -- - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
