- 论坛徽章:
- 0
|
use the idea of interrupt collapsing. In swirq context, just return if work tiems to process is less than a threshold, or say every 1 out of 100 soft irqs. It will increase some response time, but should be fine in some cases. swirq will be run quite frequently anyway, every return from hw irq handler, every system call, etc.
also consider to use workqueue or tasklet for softirq handling:
1) tasklet of same type will only be run at one CPU, so that can help to reduce usage of CPU, but again response time can hurt a bit;
2) workqueue can block, it's a thread context not interrupt context, so it will still endup using normal sys CPU time compared to softirq CPU, and it can sleep when nothing to do. I don't expect much reponse time increase in this approach, just a bot for context switch inside kernel, only when time share expired or there is nothing to do more. |
|