蜗窝科技

@anchen：你遇到的这个问题其实就是cache coherence的问题。根据你的描述，DMAC总是通过ACP访问L2 cache，而这就导致了你无论使用O_SYNC或者不使用O_SYNC都是错误的： 1、使用了O_SYNC，那么你的驱动在访问mmap返回的那些地址的时候是non cache的，也就是说，数据直接去到main memory，而不会操作L2 cache。对于DMAC，它的访问需要通过L2 cache，由于第一次访问的时候，L2是all invalidate的，因此数据访问都是cache miss的，需要从main memory加载数据并更新到L2 cache。后续，程序再次更新通过mmap返回的那些地址进行数据更新的时候，直达main memory，但是DMAC在访问的时候，L2 cache hit，从而不会访问main memory，从而导致运行失败。 2、不使用O_SYNC的时候，你的驱动在访问mmap返回的那些地址的时候是cache的，但是首先进入的是L1 cache（我猜测cache 策略是write back的），而不会操作L2 cache，因此，DMAC也不能从L2中获取正确的数据。 怎么破呢？我觉得首先是应该mapping成cache的，但是要辅以一些同步的手段和cache维护的指令。也就是说，当你的程序通过mmap返回的那些地址完成数据更新之后，要clean到POC，让系统中的所有的observer（CPU core和DMAC等等）看到一致性的数据。 BTW， invalidate操作不适合，我们这个场合需要的是将L1的数据write back到L2，invalidate是将cache中的数据设置为无效。另外，cache操作其实无法操作到指定的某个level的cache，只能是poc或者是pou。不过其实你没有详细描述你系统的memory hierarchy，因此上面我建议使用poc。

@anchen：我觉得你的需求应该就是invalidate l2 cache？ 以arm平台为例，其实就是一条写p15协处理器的指令（当然，需要一些内存屏障操作）。 arm平台为这个需求抽象出来了一系列的接口，头文件在：arch/arm/include/asm/outercache.h 可以参考kernel中某些CPU的实现，例如：arch/arm/mm/cache-feroceon-l2.c 当然，如果粗暴一些，你也可以自己写一个，开放给用户空间程序使用。 不知道还有没有其它好的方法？知道的同学也吱一声~~~

@linuxer：感谢您的回复！看来我理解错了，但其实我两个都试了，无论是加还是不加 O_SYNC，结果似乎都是直接写入最终的设备地址，而没有同时更新到cache。有没有什么办法可以满足我的要求，写入最终设备的同时，更新到cache？或者说，如何在更新物理设备的同时，能够在用户空间，失效相对应的那部分cache？对现在的情况来说，我只要求物理memory和L2 cache能保持一致就可以了。

@linuxer：哦，我明白了，谢谢linuxer不耐其烦的答惑，^_^

@linuxer：@西人，对于bounded类型的workqueue，其实不需要workqueue->pwqs这个链表也OK的，当需要遍历一个workqueue上的所有pool_workqueue节点的时候，通过workqueue->cpu_pwqs就OK了，但是，这仅限于bounded类型的workqueue，对于unbound类型的workqueue，其线程池不是per cpu的，workqueue->cpu_pwqs也就没有节点，只能是依靠workqueue->pwqs这个链表了。虽然这个设计看起来有些冗余，不过当flush或者destroy一个workqueue的时候，不需要区分workqueue的类型，直接使用for_each_pwq就可以遍历一个workqueue上的所有pool_workqueue了。

@linuxer：那我觉得既然已经在workqueue->cpu_pwqs有pool_workqueue的节点了，为什么还要有workqueue->pwqs这个链表来多此一举呢，感觉这不是重复了吗？对这点还不是很明白，难道有其他用途吗

@anchen：如果在open /dev/mem这个device node的时候有O_SYNC，那么，随后的mmap创建的映射将是non cache的（对于ARM64的平台，其他的平台我没有看，我估计是类似的），也就是说，你通过OcmAddr地址更新DMA微码的时候，应该不会通过cache，而直接进入最终的设备地址。

@西人：对于bounded类型的workqueue，其对应的pool_workqueue是per cpu的，如果系统中有N个cpu，那么就有N个pool_workqueue，一方面保存在workqueue->cpu_pwqs，此外，workqueue->pwqs链表中也会挂入N个pool_workqueue的节点。

@linuxer：谢谢您的回答，另外我不理解的一点是： 就像您说的，“对于bounded类型的workqueue，其对应的pool_workqueue是per cpu的”，也就是此时的workqueue->cpu_pwqs是指向一个对应的pool_workqueue，那么此时的workqueue->pwqs这个链表中，是不是只有一个pool_workqueue，就是上面那个对应的pool_workqueue啊

@西人：其实你问的问题是一个，只要能够理清workqueue、pool workqueue和worker thread pool以及worker thread之间的关系就OK了。 在过去（非CMWQ），内核抽象了workqueue、cpu workqueue和worker thread三个数据结构来完成对workqueue逻辑的控制。那时候，这三个数据结构的关系非常简单，cpu workqueue和worker thread是一一对应，而workqueue和cpu workqueue关系也非常简单，系统有多少个cpu，那么workqueue就拥有多少个cpu workqueue。为何有cpu workqueue？无它，唯性能尔。因此，对于一个workqueue的实例，其数据有两种，一种是全局的，例如workqueue的名字，这个和哪个cpu没有关系。还有有一些数据是per cpu的，例如：worker thread，work list。上面说的是通常意义的workqueue，实际上还有一种single thread workqueue，但是内核在内存分配的时候，不管是否是single thread workqueue，其对应的cpu workqueue数据结构总是per cpu分配的（没错，简直是浪费），当然，实际上对于single thread workqueue而言，我们只会使用其中之一。 来到CWMQ后，我们引入worker thread pool的概念，因此，workqueue只能看到worker thread pool这个层次，具体底层如何创建线程来处理work，它就不关心了。所以，在设计workqueue数据结构的时候，我们需要包括： （1）全局的数据成员，和哪一个worker thread pool没有关系。 （2）和worker thread pool相关的数据 如果workqueue和worker thread pool是一一对应的，那么struct workqueue_struct可以包括（1）和（2）中的成员，但是事实并非如此，一个workqueue可以对应多个worker thread pool，因此，（2）的那些数据成员被合成一个struct pool_workqueue的数据结构。 对于bounded类型的workqueue，其对应的pool_workqueue是per cpu的（参考cpu_pwqs成员），对于unbounded类型的workqueue，其对应pool_workqueue是per node的（参考pwqs和numa_pwq_tbl）。 BTW，我写文章的时候可能有些遣词不是那么规范，见谅，呵呵～～～