CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

别人的经验，我们的阶梯.

大家好，我是道哥，今天我为大伙儿解说的技术知识点是：【中断处理中的下半部分机制-工作队列】.

在刚开始介绍中断处理的时候，曾经贴出下面这张图:

图中描述了中断处理中的下半部分都有哪些机制，以及如何根据实际的业务场景、限制条件来进行选择.

可以看出：这些不同的实现之间，有些是重复的，或者是相互取代的关系.

也正因为此，它们之间的使用方式几乎是大同小异，至少是在API接口函数的使用方式上，从使用这的角度来看，都是非常类似的.

这篇文章，我们就通过实际的代码操作，来演示一下工作队列(workqueue)的使用方式.

工作队列是什么

工作队列是Linux操作系统中，进行中断下半部分处理的重要方式.

从名称上可以猜到：一个工作队列就好像业务层常用的消息队列一样，里面存放着很多的工作项等待着被处理.

工作队列中有两个重要的结构体：工作队列(workqueue_struct) 和 工作项(work_struct):

1. struct workqueue_struct {
2. struct list_head pwqs; /* WR: all pwqs of this wq */
3. struct list_head list; /* PR: list of all workqueues */
4. ...
5. char name[WQ_NAME_LEN]; /* I: workqueue name */
6. ...
7. /* hot fields used during command issue, aligned to cacheline */
8. unsigned int flags ____cacheline_aligned; /* WQ: WQ_* flags */
9. struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */
10. struct pool_workqueue __rcu *numa_pwq_tbl[]; /* PWR: unbound pwqs indexed by node */
11. };

1. struct work_struct {
2. atomic_long_t data;
3. struct list_head entry;
4. work_func_t func; // 指向处理函数
5. #ifdef CONFIG_LOCKDEP
6. struct lockdep_map lockdep_map;
7. #endif
8. };

在内核中，工作队列中的所有工作项，是通过链表串在一起的，并且等待着操作系统中的某个线程挨个取出来处理.

这些线程，可以是由驱动程序通过 kthread_create 创建的线程，也可以是由操作系统预先就创建好的线程.

这里就涉及到一个取舍的问题了.

如果我们的处理函数很简单，那么就没有必要创建一个单独的线程来处理了.

原因有二:

1. 创建一个内核线程是很耗费资源的，如果函数很简单，很快执行结束之后再关闭线程，太划不来了，得不偿失;
2. 如果每一个驱动程序编写者都毫无节制地创建内核线程，那么内核中将会存在大量不必要的线程，当然了本质上还是系统资源消耗和执行效率的问题;

为了避免这种情况，于是操作系统就为我们预先创建好一些工作队列和内核线程.

我们只需要把需要处理的工作项，直接添加到这些预先创建好的工作队列中就可以了，它们就会被相应的内核线程取出来处理.

例如下面这些工作队列，就是内核默认创建的(include/linux/workqueue.h):

1. /*
2. * System-wide workqueues which are always present.
3. *
4. * system_wq is the one used by schedule[_delayed]_work[_on]().
5. * Multi-CPU multi-threaded. There are users which expect relatively
6. * short queue flush time. Don't queue works which can run for too
7. * long.
8. *
9. * system_highpri_wq is similar to system_wq but for work items which
10. * require WQ_HIGHPRI.
11. *
12. * system_long_wq is similar to system_wq but may host long running
13. * works. Queue flushing might take relatively long.
14. *
15. * system_unbound_wq is unbound workqueue. Workers are not bound to
16. * any specific CPU, not concurrency managed, and all queued works are
17. * executed immediately as long as max_active limit is not reached and
18. * resources are available.
19. *
20. * system_freezable_wq is equivalent to system_wq except that it's
21. * freezable.
22. *
23. * *_power_efficient_wq are inclined towards saving power and converted
24. * into WQ_UNBOUND variants if 'wq_power_efficient' is enabled; otherwise,
25. * they are same as their non-power-efficient counterparts - e.g.
26. * system_power_efficient_wq is identical to system_wq if
27. * 'wq_power_efficient' is disabled. See WQ_POWER_EFFICIENT for more info.
28. */
30. extern struct workqueue_struct *system_wq;
31. extern struct workqueue_struct *system_highpri_wq;
32. extern struct workqueue_struct *system_long_wq;
33. extern struct workqueue_struct *system_unbound_wq;
34. extern struct workqueue_struct *system_freezable_wq;
35. extern struct workqueue_struct *system_power_efficient_wq;
36. extern struct workqueue_struct *system_freezable_power_efficient_wq;

以上这些默认工作队列的创建代码是(kernel/workqueue.c):

1. int __init workqueue_init_early(void)
2. {
3. ...
4. system_wq = alloc_workqueue("events", 0, 0);
5. system_highpri_wq = alloc_workqueue("events_highpri", WQ_HIGHPRI, 0);
6. system_long_wq = alloc_workqueue("events_long", 0, 0);
7. system_unbound_wq = alloc_workqueue("events_unbound", WQ_UNBOUND,
8. WQ_UNBOUND_MAX_ACTIVE);
9. system_freezable_wq = alloc_workqueue("events_freezable",
10. WQ_FREEZABLE, 0);
11. system_power_efficient_wq = alloc_workqueue("events_power_efficient",
12. WQ_POWER_EFFICIENT, 0);
13. system_freezable_power_efficient_wq = alloc_workqueue("events_freezable_power_efficient",
14. WQ_FREEZABLE | WQ_POWER_EFFICIENT,
15. 0);
16. ...
17. }

此外，由于工作队列 system_wq 被使用的频率很高，于是内核就封装了一个简单的函数(schedule_work)给我们使用:

1. /**
2. * schedule_work - put work task in global workqueue
3. * @work: job to be done
4. *
5. * Returns %false if @work was already on the kernel-global workqueue and
6. * %true otherwise.
7. *
8. * This puts a job in the kernel-global workqueue if it was not already
9. * queued and leaves it in the same position on the kernel-global
10. * workqueue otherwise.
11. */
13. static inline bool schedule_work(struct work_struct *work){
14. return queue_work(system_wq, work);
15. }

当然了，任何事情有利就有弊.

由于内核默认创建的工作队列，是被所有的驱动程序共享的.

如果所有的驱动程序都把等待处理的工作项委托给它们来处理，那么就会导致某个工作队列中过于拥挤.

根据先来后到的原则，工作队列中后加入的工作项，就可能因为前面工作项的处理函数执行的时间太长，从而导致时效性无法保证.

因此，这里存在一个系统平衡的问题.

关于工作队列的基本知识点就介绍到这里，下面来实际操作验证一下.

驱动程序

之前的几篇文章，在驱动程序中测试中断处理的操作流程都是一样的，因此这里就不在操作流程上进行赘述了.

这里直接给出驱动程序的全貌代码，然后查看 dmesg 的输出信息.

创建驱动程序源文件和 Makefile:

1. $ cd tmp/linux-4.15/drivers
2. $ mkdir my_driver_interrupt_wq
3. $ touch my_driver_interrupt_wq.c
4. $ touch Makefile

示例代码全貌

测试场景是：加载驱动模块之后，如果监测到键盘上的ESC键被按下，那么就往内核默认的工作队列system_wq中增加一个工作项，然后观察该工作项对应的处理函数是否被调用.

1. #include
2. #include
3. #include
5. static int irq;
6. static char * devname;
8. static struct work_struct mywork;
10. // 接收驱动模块加载时传入的参数
11. module_param(irq, int, 0644);
12. module_param(devname, charp, 0644);
14. // 定义驱动程序的 ID，在中断处理函数中用来判断是否需要处理
15. #define MY_DEV_ID 1226
17. // 驱动程序数据结构
18. struct myirq
19. {
20. int devid;
21. };
23. struct myirq mydev ={ MY_DEV_ID };
25. #define KBD_DATA_REG 0x60
26. #define KBD_STATUS_REG 0x64
27. #define KBD_SCANCODE_MASK 0x7f
28. #define KBD_STATUS_MASK 0x80
30. // 工作项绑定的处理函数
31. static void mywork_handler(struct work_struct *work)
32. {
33. printk("mywork_handler is called. \n");
34. // do some other things
35. }
37. //中断处理函数
38. static irqreturn_t myirq_handler(int irq, void * dev)
39. {
40. struct myirq mydev;
41. unsigned char key_code;
42. mydev = *(struct myirq*)dev;
44. // 检查设备 id，只有当相等的时候才需要处理
45. if (MY_DEV_ID == mydev.devid)
46. {
47. // 读取键盘扫描码
48. key_code = inb(KBD_DATA_REG);
50. if (key_code == 0x01)
51. {
52. printk("ESC key is pressed! \n");
54. // 初始化工作项
55. INIT_WORK(&mywork, mywork_handler);
57. // 加入到工作队列 system_wq
58. schedule_work(&mywork);
59. }
60. }
62. return IRQ_HANDLED;
63. }
65. // 驱动模块初始化函数
66. static int __init myirq_init(void)
67. {
68. printk("myirq_init is called. \n");
70. // 注册中断处理函数
71. if(request_irq(irq, myirq_handler, IRQF_SHARED, devname, &mydev)!=0)
72. {
73. printk("register irq[%d] handler failed. \n", irq);
74. return -1;
75. }
77. printk("register irq[%d] handler success. \n", irq);
78. return 0;
79. }
81. // 驱动模块退出函数
82. static void __exit myirq_exit(void)
83. {
84. printk("myirq_exit is called. \n");
86. // 释放中断处理函数
87. free_irq(irq, &mydev);
88. }
90. MODULE_LICENSE("GPL");
91. module_init(myirq_init);
92. module_exit(myirq_exit);

ntk("myirq_exit is called. \n"); // 释放中断处理函数 free_irq(irq, &mydev);} MODULE_LICENSE("GPL");module_init(myirq_init);module_exit(myirq_exit),

Makefile 文件

1. ifneq ($(KERNELRELEASE),)
2. obj-m := my_driver_interrupt_wq.o
3. else
4. KERNELDIR ?= /lib/modules/$(shell uname -r)/build
5. PWD := $(shell pwd)
6. default:
7. $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
8. clean:
9. $(MAKE) -C $(KERNEL_PATH) M=$(PWD) clean
10. endif

编译、测试

1. $ make
2. $ sudo insmod my_driver_interrupt_wq.ko irq=1 devname=mydev

检查驱动模块是否加载成功:

1. $ lsmod | grep my_driver_interrupt_wq
2. my_driver_interrupt_wq 16384 0

再看一下 dmesg 的输出信息:

1. $ dmesg
2. ...
3. [ 188.247636] myirq_init is called.
4. [ 188.247642] register irq[1] handler success.

说明：驱动程序的初始化函数 myirq_init 被调用了，并且成功注册了 1 号中断的处理程序.

此时，按一下键盘上的 ESC 键.

操作系统在捕获到键盘中断之后，会依次调用此中断的所有中断处理程序，其中就包括我们注册的 myirq_handler 函数.

在这个函数中，当判断出是ESC按键时，就初始化一个工作项(把结构体 work_struct 类型的变量与一个处理函数绑定起来)，然后丢给操作系统预先创建好的工作队列(system_wq)去处理，如下所示:

1. if (key_code == 0x01)
2. {
3. printk("ESC key is pressed! \n");
4. INIT_WORK(&mywork, mywork_handler);
5. schedule_work(&mywork);
6. }

因此，当相应的内核线程从这个工作队列(system_wq)中取出工作项(mywork)来处理的时候，函数 mywork_handler 就会被调用.

现在来看一下 dmesg 的输出信息:

1. [ 305.053155] ESC key is pressed!
2. [ 305.053177] mywork_handler is called.

可以看到：mywork_handler函数被正确调用了.

完美.

本文转载自微信公众号「IOT物联网小镇」 。

原文链接：https://mp.weixin.qq.com/s/Kvsz-rsPSTdcvY9PWPz9Sg 。

最后此篇关于Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？的文章就讲到这里了,如果你想了解更多关于Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。