周日回来加班，小声问个关于workqueue问题

imlvye

       linux驱动里面使用create_singlethread_workqueue建立了一个单线程workqueue, 然后在中断处理函数中使用queue_work函数把任务放到workqueue中处理，但任务出来的速度比较慢，而中断的速度比较快，想问下这样长时间下会不会引起workqueue的 溢出或者是简单丢掉下任务？
      然后我看ULK中说flush_workqueue函数会等待工作队列中所以挂起的任务执行完成，但我的实践是调用flush后很快就返回了，好像没有去执行挂起的处理，是不是让workqueue丢掉了呢？

MagicBoy2010

linux驱动里面使用create_singlethread_workqueue建立了一个单线程workqueue, 然后在中断处理函数中使用queue_work函数把任务放到workqueue中处理，但任务出来的速度比较慢，而中断的速度比较快，想问下这样长时间下会不会引起workqueue的 溢出或者是简单丢掉下任务？
      然后我看ULK中说flush_workqueue函数会等待工作队列中所以挂起的任务执行完成，但我的实践是调用flush后很快就返回了，好像没有去执行挂起的处理，是不是让workqueue丢掉了呢？

=============================================================

问题的关键在于，你是否会在中断处理函数中提交不同的struct work_struct对象，换句话说是否你在每次中断到来时要执行不同的操作，如果是，work_struct本身有链表机制，极端情形下导致内存分配失败是可能的。但是现实中，很少会在每次中断，比如网卡显示有数据到达时，提交不同的工作节点。如果你的中断处理函数中提交相同工作结点的话，《深入Linux设备驱动程序内核机制》 6.2.5节“提交工作节点queue_work"的叙述是："(queue_work_on)函数首先检测work->data的WORK_STRUCT_PENDING位有没有被置1，置1的话意味着此前该work已被提交还没有处理，内核禁止驱动程序在一个工作结点还没处理完就再次提交该结点"，所以即便中断发生了10次，但是工作结点可能只提交了一个。  简言之，work_queue应该按照要处理的不同任务提交不同节点，而代表相同任务的工作节点只应该出现一次。flush_workqueue使用COMPLETION机制确保所有在该函数调用前提交的节点都会被执行完毕，但是之后提交的节点它就管不着了。

imlvye

谢谢，我提交的是相同的work节点，那就是说当工作队列处理不过来的时候丢弃了很多。

MagicBoy2010

楼上的其实也不用担心丢掉的工作节点，因为假设网卡自己数据没丢，你只要提交了一个节点，当被调度执行时还是会给DMA到系统内存中的。这个跟softirq机制差不多：同一件事提交一次就够了。
另外感谢版主加分，呵呵。

linuxfellow

回复 2# MagicBoy2010
这样举个例子会更清楚：

如果3个中断源(S1,S2,S3)共用一个中断信号： INTn
S1 对应的中断下半部为 tasklet1
S2 对应的中断下半部为  tasklet2
S3 对应的中断下半部为  tasklet2
同一个中断信号其下半部有可能重叠：如中断源 S1/S2通过中断INTn能重叠提交他们的下半部。
但中断源S2/S3其下半部就不可同时提交。在实际实现时最好秉承哪里的问题哪里解决的原则，不完全寄希望于系统，在执行完tasklet2之前屏蔽掉S2/S3,这样interrupt reentry就不会发生，有利于系统的性能提高。


   

MagicBoy2010

这样举个例子会更清楚：

如果3个中断源(S1,S2,S3)共用一个中断信号： INTn
S1 对应的中断下半部为 tasklet1
S2 对应的中断下半部为  tasklet2
S3 对应的中断下半部为  tasklet2
同一个中断信号其下半部有可能重叠：如中断源 S1/S2通过中断INTn能重叠提交他们的下半部。
但中断源S2/S3其下半部就不可同时提交。在实际实现时最好秉承哪里的问题哪里解决的原则，不完全寄希望于系统，在执行完tasklet2之前屏蔽掉S2/S3,这样interrupt reentry就不会发生，有利于系统的性能提高。
============================================================

不错，很好的例子。最后一点，tasklet(softirq的一种)在执行时属于中断上下文， in_interrupt()， 所以tasklet在执行时，不会有reentry的问题。

linuxfellow

回复 6# MagicBoy2010
是的， softirq不会reentry. 我的本意是：在tasklet2执行完之前，INTn不要再被S2/S3触发，s2/s3中断的前半部也不应该发生。因为即使触发了，其下半部也会被忽略，白白增加系统中断负担。
   

MagicBoy2010

是的， softirq不会reentry. 我的本意是：在tasklet2执行完之前，INTn不要再被S2/S3触发，s2/s3中断的前半部也不应该发生。因为即使触发了，其下半部也会被忽略，白白增加系统中断负担。
==================================================================
事实上在整个tasklet执行过程中，内核都是将外部中断打开的，所以tasklet执行时，是允许外部中断进来的。你的说法恰好违反了softirq的本意，因为s2/s3的前半部分极大的可能是会重新提交一个tasklet，虽然这次的中断不会导致reentry正在执行的tasklet，但是tasklet在执行时会重新检查有无新的tasklet正在被加入(pending), 具体代码框架：

__do_softirq(void)
{
    ...
restart:
     ...
     do{
     ..
     }while(pending);
   
    pending = local_softirq_pending(); //重新检查有无新的softirq pending...
    if(pending && --max_restart)
       goto restart;

MagicBoy2010

除非出于保护系统共享资源的需要，系统应该尽可能地开放响应外部中断的能力，否则会带来很多问题。这也是为什么Linux内核有hardirq和softirq的主要原因。

linuxfellow

回复 9# MagicBoy2010
只屏蔽S2/S3中断源，其他中断都开放；如果S2/S3再次发生中断， 只能执行前半部没有任何意义。屏蔽S2/S3对其他中断没有任何影响。