蜗窝科技

@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，我写文章的时候可能有些遣词不是那么规范，见谅，呵呵～～～

@wowo：linuxer大神，请指点一下吧，谢谢，上面的格式真乱，我重写两个问题： （1）对于文中一段话，“workqueue中的成员包括两个类别：global类型和per thread pool类型的，我们把那些per thread pool 类型的数据集合起来就形成了pool_workqueue的定义。”感觉是不是有歧义啊，这样感觉只有per thread pool类型的才能是 pool_workqueue的 （2）根据workqueue_attrs，一个workqueue_struct会对应一个worker_pool，pool_workqueue是中间桥梁，而一个pool_workqueue 对应一个worker_pool，那么应该是一个workqueue_struct会对应一个pool_workqueue，为什么还会有workqueue_struct->pwqs这个链表来连接好几个pool_workqueue啊

@linuxer：您好！我想请教一个和O_SYNC有关的具体问题。 我的系统是Altera的SoC，我要在用户空间为DMAC（pl330）更新其微码，结果发现DMA第一次运行正常，第二次运行依然执行前一次操作（虽然微码中的源和目的我都更新过了）。现在的结论是，因为这个SoC的架构，DMAC总是通过ACP访问L2 cache，意外着，DMA第一次会将微码锁存在L2 cache中，而用户空间在更新微码的过程中，没有处理L2 cache和memory的一致性，造成DMA第二次访问时，L2 cache依然命中，所以再次运行第一次的操作。我考虑过如下O_SYNC的使用，但也没有成功，不知道这样使用对不对？ FdforOcm = open("/dev/mem", O_RDWR | O_SYNC); OcmAddr = mmap(NULL, 0x40000, PROT_READ|PROT_WRITE, MAP_SHARED, FdforOcm, 0xFFE00000); //这个返回的地址用来给程序更新DMA微码，使用O_SYNC，意味着一定会写入cache，然后更新memory吗？ FdforDMA = open("/dev/mem", O_RDWR); DMAAddr = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, FdforDMA, 0xFFDA0000); //这个返回的地址用来给程序访问DMA的寄存器

@linuxer：您好！我想请教一个和O_SYNC有关的具体问题。 我的系统是Altera的SoC，我要在用户空间为DMAC（pl330）更新其微码，结果发现DMA第一次运行正常，第二次运行依然执行前一次操作（虽然微码中的源和目的我都更新过了）。现在的结论是，因为这个SoC的架构，DMAC总是通过ACP访问L2 cache，意外着，DMA第一次会将微码锁存在L2 cache中，而用户空间在更新微码的过程中，没有处理L2 cache和memory的一致性，造成DMA第二次访问时，L2 cache依然命中，所以再次运行第一次的操作。我考虑过如下O_SYNC的使用，但也没有成功，不知道这样使用对不对？ FdforOcm = open("/dev/mem", O_RDWR | O_SYNC); OcmAddr = mmap(NULL, 0x40000, PROT_READ|PROT_WRITE, MAP_SHARED, FdforOcm, 0xFFE00000); //这个返回的地址用来给程序更新DMA微码，使用O_SYNC，意味着一定会写入cache，然后更新memory吗？ FdforDMA = open("/dev/mem", O_RDWR); DMAAddr = mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, FdforDMA, 0xFFDA0000); //这个返回的地址用来给程序访问DMA的寄存器

这篇文章来的太及时了，前两天正准备部关于tty的相关东西，有一些概念还没有理清楚： terminal console vt tty pseudo terminal等，再加上control terminal, session等 纠缠在一起！