Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？

大家都叫我云姐 發表於 2024-1-1 00:00:00

Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？

<img title="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" alt="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" border="0" src="https://zhuji.jb51.net/uploads/img/202305/d8a04a44a5d539855ff04094601ab338.jpg">

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


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


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


<img title="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" alt="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" border="0" src="https://zhuji.jb51.net/uploads/img/202305/96c9410bc140ae7df243f5aa2461a1e5.jpg">

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


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


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


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

<h3>
工作队列是什么
</h3>

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


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


<img title="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" alt="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" border="0" src="https://zhuji.jb51.net/uploads/img/202305/9b3c6d96d1ca87abb1030baf17143714.jpg">

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

<ol class="dp-sql">
<li class="alt">
struct workqueue_struct { 
</li>
<li>
struct list_head pwqs; /* WR: all pwqs of this wq */ 
</li>
<li class="alt">
struct list_head list; /* PR: list of all workqueues */ 
</li>
<li>
... 
</li>
<li class="alt">
char name; /* I: workqueue name */ 
</li>
<li>
... 
</li>
<li class="alt">
/* hot fields used during command issue, aligned to cacheline */ 
</li>
<li>
unsigned int flags ____cacheline_aligned; /* WQ: WQ_* flags */ 
</li>
<li class="alt">
struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */ 
</li>
<li>
struct pool_workqueue __rcu *numa_pwq_tbl[]; /* PWR: unbound pwqs indexed by node */ 
</li>
<li class="alt">
}; 
</li>
</ol>
<ol class="dp-sql">
<li class="alt">
struct work_struct { 
</li>
<li>
atomic_long_t data; 
</li>
<li class="alt">
struct list_head entry; 
</li>
<li>
work_func_t func; // 指向处理函数 
</li>
<li class="alt">
#ifdef CONFIG_LOCKDEP 
</li>
<li>
struct lockdep_map lockdep_map; 
</li>
<li class="alt">
#endif 
</li>
<li>
}; 
</li>
</ol>

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


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


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


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


原因有二：

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

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


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


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

<ol class="dp-sql">
<li class="alt">
/* 
</li>
<li>
* System-wide workqueues which are always present. 
</li>
<li class="alt">
* 
</li>
<li>
* system_wq is the one used by schedule_work(). 
</li>
<li class="alt">
* Multi-CPU multi-threaded. There are users which expect relatively 
</li>
<li>
* short queue flush time. Don't queue works which can run for too 
</li>
<li class="alt">
* long. 
</li>
<li>
* 
</li>
<li class="alt">
* system_highpri_wq is similar to system_wq but for work items which 
</li>
<li>
* require WQ_HIGHPRI. 
</li>
<li class="alt">
* 
</li>
<li>
* system_long_wq is similar to system_wq but may host long running 
</li>
<li class="alt">
* works. Queue flushing might take relatively long. 
</li>
<li>
* 
</li>
<li class="alt">
* system_unbound_wq is unbound workqueue. Workers are not bound to 
</li>
<li>
* any specific CPU, not concurrency managed, and all queued works are 
</li>
<li class="alt">
* executed immediately as long as max_active limit is not reached and 
</li>
<li>
* resources are available. 
</li>
<li class="alt">
* 
</li>
<li>
* system_freezable_wq is equivalent to system_wq except that it's 
</li>
<li class="alt">
* freezable. 
</li>
<li>
* 
</li>
<li class="alt">
* *_power_efficient_wq are inclined towards saving power and converted 
</li>
<li>
* into WQ_UNBOUND variants if 'wq_power_efficient' is enabled; otherwise, 
</li>
<li class="alt">
* they are same as their non-power-efficient counterparts - e.g. 
</li>
<li>
* system_power_efficient_wq is identical to system_wq if 
</li>
<li class="alt">
* 'wq_power_efficient' is disabled. See WQ_POWER_EFFICIENT for more info. 
</li>
<li>
*/ 
</li>
<li class="alt">

</li>
<li>
extern struct workqueue_struct *system_wq; 
</li>
<li class="alt">
extern struct workqueue_struct *system_highpri_wq; 
</li>
<li>
extern struct workqueue_struct *system_long_wq; 
</li>
<li class="alt">
extern struct workqueue_struct *system_unbound_wq; 
</li>
<li>
extern struct workqueue_struct *system_freezable_wq; 
</li>
<li class="alt">
extern struct workqueue_struct *system_power_efficient_wq; 
</li>
<li>
extern struct workqueue_struct *system_freezable_power_efficient_wq; 
</li>
</ol>

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

<ol class="dp-sql">
<li class="alt">
int __init workqueue_init_early(void) 
</li>
<li>
{ 
</li>
<li class="alt">
... 
</li>
<li>
system_wq = alloc_workqueue("events", 0, 0); 
</li>
<li class="alt">
system_highpri_wq = alloc_workqueue("events_highpri", WQ_HIGHPRI, 0); 
</li>
<li>
system_long_wq = alloc_workqueue("events_long", 0, 0); 
</li>
<li class="alt">
system_unbound_wq = alloc_workqueue("events_unbound", WQ_UNBOUND, 
</li>
<li>
WQ_UNBOUND_MAX_ACTIVE); 
</li>
<li class="alt">
system_freezable_wq = alloc_workqueue("events_freezable", 
</li>
<li>
WQ_FREEZABLE, 0); 
</li>
<li class="alt">
system_power_efficient_wq = alloc_workqueue("events_power_efficient", 
</li>
<li>
WQ_POWER_EFFICIENT, 0); 
</li>
<li class="alt">
system_freezable_power_efficient_wq = alloc_workqueue("events_freezable_power_efficient", 
</li>
<li>
WQ_FREEZABLE | WQ_POWER_EFFICIENT, 
</li>
<li class="alt">
0); 
</li>
<li>
... 
</li>
<li class="alt">
} 
</li>
</ol>

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

<ol class="dp-sql">
<li class="alt">
/** 
</li>
<li>
* schedule_work - put work task in global workqueue 
</li>
<li class="alt">
* @work: job to be done 
</li>
<li>
* 
</li>
<li class="alt">
* Returns %false if @work was already on the kernel-global workqueue and 
</li>
<li>
* %true otherwise. 
</li>
<li class="alt">
* 
</li>
<li>
* This puts a job in the kernel-global workqueue if it was not already 
</li>
<li class="alt">
* queued and leaves it in the same position on the kernel-global 
</li>
<li>
* workqueue otherwise. 
</li>
<li class="alt">
*/ 
</li>
<li>

</li>
<li class="alt">
static inline bool schedule_work(struct work_struct *work){ 
</li>
<li>
return queue_work(system_wq, work); 
</li>
<li class="alt">
} 
</li>
</ol>

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


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


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


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


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


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

<h3>
驱动程序
</h3>

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


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


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

<ol class="dp-sql">
<li class="alt">
$ cd tmp/linux-4.15/drivers 
</li>
<li>
$ mkdir my_driver_interrupt_wq 
</li>
<li class="alt">
$ touch my_driver_interrupt_wq.c 
</li>
<li>
$ touch Makefile 
</li>
</ol>
<h3>
示例代码全貌
</h3>

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

<ol class="dp-sql">
<li class="alt">
#include <linux kernel.h></linux>
</li>
<li>
#include <linux module.h></linux>
</li>
<li class="alt">
#include <linux interrupt.h></linux>
</li>
<li>

</li>
<li class="alt">
static int irq; 
</li>
<li>
static char * devname; 
</li>
<li class="alt">

</li>
<li>
static struct work_struct mywork; 
</li>
<li class="alt">

</li>
<li>
// 接收驱动模块加载时传入的参数 
</li>
<li class="alt">
module_param(irq, int, 0644); 
</li>
<li>
module_param(devname, charp, 0644); 
</li>
<li class="alt">

</li>
<li>
// 定义驱动程序的 ID，在中断处理函数中用来判断是否需要处理 
</li>
<li class="alt">
#define MY_DEV_ID 1226 
</li>
<li>

</li>
<li class="alt">
// 驱动程序数据结构 
</li>
<li>
struct myirq 
</li>
<li class="alt">
{ 
</li>
<li>
int devid; 
</li>
<li class="alt">
}; 
</li>
<li>

</li>
<li class="alt">
struct myirq mydev ={ MY_DEV_ID }; 
</li>
<li>

</li>
<li class="alt">
#define KBD_DATA_REG 0x60 
</li>
<li>
#define KBD_STATUS_REG 0x64 
</li>
<li class="alt">
#define KBD_SCANCODE_MASK 0x7f 
</li>
<li>
#define KBD_STATUS_MASK 0x80 
</li>
<li class="alt">

</li>
<li>
// 工作项绑定的处理函数 
</li>
<li class="alt">
static void mywork_handler(struct work_struct *work) 
</li>
<li>
{ 
</li>
<li class="alt">
printk("mywork_handler is called. \n"); 
</li>
<li>
// do some other things 
</li>
<li class="alt">
} 
</li>
<li>

</li>
<li class="alt">
//中断处理函数 
</li>
<li>
static irqreturn_t myirq_handler(int irq, void * dev) 
</li>
<li class="alt">
{ 
</li>
<li>
struct myirq mydev; 
</li>
<li class="alt">
unsigned char key_code; 
</li>
<li>
mydev = *(struct myirq*)dev; 
</li>
<li class="alt">

</li>
<li>
// 检查设备 id，只有当相等的时候才需要处理 
</li>
<li class="alt">
if (MY_DEV_ID == mydev.devid) 
</li>
<li>
{ 
</li>
<li class="alt">
// 读取键盘扫描码 
</li>
<li>
key_code = inb(KBD_DATA_REG); 
</li>
<li class="alt">

</li>
<li>
if (key_code == 0x01) 
</li>
<li class="alt">
{ 
</li>
<li>
printk("ESC key is pressed! \n"); 
</li>
<li class="alt">

</li>
<li>
// 初始化工作项 
</li>
<li class="alt">
INIT_WORK(&mywork, mywork_handler); 
</li>
<li>

</li>
<li class="alt">
// 加入到工作队列 system_wq 
</li>
<li>
schedule_work(&mywork); 
</li>
<li class="alt">
} 
</li>
<li>
} 
</li>
<li class="alt">

</li>
<li>
return IRQ_HANDLED; 
</li>
<li class="alt">
} 
</li>
<li>

</li>
<li class="alt">
// 驱动模块初始化函数 
</li>
<li>
static int __init myirq_init(void) 
</li>
<li class="alt">
{ 
</li>
<li>
printk("myirq_init is called. \n"); 
</li>
<li class="alt">

</li>
<li>
// 注册中断处理函数 
</li>
<li class="alt">
if(request_irq(irq, myirq_handler, IRQF_SHARED, devname, &mydev)!=0) 
</li>
<li>
{ 
</li>
<li class="alt">
printk("register irq[%d] handler failed. \n", irq); 
</li>
<li>
return -1; 
</li>
<li class="alt">
} 
</li>
<li>

</li>
<li class="alt">
printk("register irq[%d] handler success. \n", irq); 
</li>
<li>
return 0; 
</li>
<li class="alt">
} 
</li>
<li>

</li>
<li class="alt">
// 驱动模块退出函数 
</li>
<li>
static void __exit myirq_exit(void) 
</li>
<li class="alt">
{ 
</li>
<li>
printk("myirq_exit is called. \n"); 
</li>
<li class="alt">

</li>
<li>
// 释放中断处理函数 
</li>
<li class="alt">
free_irq(irq, &mydev); 
</li>
<li>
} 
</li>
<li class="alt">

</li>
<li>
MODULE_LICENSE("GPL"); 
</li>
<li class="alt">
module_init(myirq_init); 
</li>
<li>
module_exit(myirq_exit); 
</li>
</ol>

<linux kernel.h=""><linux module.h=""><linux interrupt.h="">ntk("myirq_exit is called. \n"); // 释放中断处理函数 free_irq(irq, &mydev);} MODULE_LICENSE("GPL");module_init(myirq_init);module_exit(myirq_exit);</linux></linux></linux>
<h3>
Makefile 文件
</h3>
<ol class="dp-sql">
<li class="alt">
ifneq ($(KERNELRELEASE),) 
</li>
<li>
obj-m := my_driver_interrupt_wq.o 
</li>
<li class="alt">
else 
</li>
<li>
KERNELDIR ?= /lib/modules/$(shell uname -r)/build 
</li>
<li class="alt">
PWD := $(shell pwd) 
</li>
<li>
default: 
</li>
<li class="alt">
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules 
</li>
<li>
clean: 
</li>
<li class="alt">
$(MAKE) -C $(KERNEL_PATH) M=$(PWD) clean 
</li>
<li>
endif 
</li>
</ol>
<h3>
编译、测试
</h3>
<ol class="dp-sql">
<li class="alt">
$ make 
</li>
<li>
$ sudo insmod my_driver_interrupt_wq.ko irq=1 devname=mydev 
</li>
</ol>

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

<ol class="dp-sql">
<li class="alt">
$ lsmod | grep my_driver_interrupt_wq 
</li>
<li>
my_driver_interrupt_wq 16384 0 
</li>
</ol>

再看一下 dmesg 的输出信息：

<ol class="dp-sql">
<li class="alt">
$ dmesg 
</li>
<li>
... 
</li>
<li class="alt">
[ 188.247636] myirq_init is called. 
</li>
<li>
[ 188.247642] register irq handler success. 
</li>
</ol>

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


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


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


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

<ol class="dp-sql">
<li class="alt">
if (key_code == 0x01) 
</li>
<li>
{ 
</li>
<li class="alt">
printk("ESC key is pressed! \n"); 
</li>
<li>
INIT_WORK(&mywork, mywork_handler); 
</li>
<li class="alt">
schedule_work(&mywork); 
</li>
<li>
} 
</li>
</ol>

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


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

<ol class="dp-sql">
<li class="alt">
[ 305.053155] ESC key is pressed! 
</li>
<li>
[ 305.053177] mywork_handler is called. 
</li>
</ol>

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


完美!


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


<img title="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" alt="Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？" border="0" src="https://zhuji.jb51.net/uploads/img/202305/67434cdb9ca3fe3cb2ab83e76ad478dd.jpg">
原文链接：https://mp.weixin.qq.com/s/Kvsz-rsPSTdcvY9PWPz9Sg

頁: [1]

琼殿技术论坛's Archiver

Linux驱动实践：中断处理中的【工作队列】 Workqueue 是什么鬼？