Loading [MathJax]/jax/output/CommonHTML/config.js
部署DeepSeek模型,进群交流最in玩法!
立即加群
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Linux驱动实践:中断处理中的【工作队列】 workqueue 是什么鬼?

Linux驱动实践:中断处理中的【工作队列】 workqueue 是什么鬼?

作者头像
IOT物联网小镇
发布于 2021-12-28 02:50:36
发布于 2021-12-28 02:50:36
2.1K00
代码可运行
举报
文章被收录于专栏:IOT物联网小镇IOT物联网小镇
运行总次数:0
代码可运行

目录

  • 工作队列是什么
  • 驱动程序
  • 编译、测试

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

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

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

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

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

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

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

工作队列是什么

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

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
struct workqueue_struct {
    struct list_head        pwqs;           /* WR: all pwqs of this wq */
    struct list_head        list;           /* PR: list of all workqueues */
    ...
    char                    name[WQ_NAME_LEN]; /* I: workqueue name */
    ...
    /* hot fields used during command issue, aligned to cacheline */
    unsigned int            flags ____cacheline_aligned; /* WQ: WQ_* flags */
    struct pool_workqueue __percpu *cpu_pwqs; /* I: per-cpu pwqs */
    struct pool_workqueue __rcu *numa_pwq_tbl[]; /* PWR: unbound pwqs indexed by node */
};
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
struct work_struct {
        atomic_long_t data;
        struct list_head entry;
        work_func_t func;   // 指向处理函数
#ifdef CONFIG_LOCKDEP                                                                                   
        struct lockdep_map lockdep_map;
#endif
};

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

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

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

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

原因有二:

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

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

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
/*
 * System-wide workqueues which are always present.
 *
 * system_wq is the one used by schedule[_delayed]_work[_on]().
 * Multi-CPU multi-threaded.  There are users which expect relatively
 * short queue flush time.  Don't queue works which can run for too
 * long.
 *
 * system_highpri_wq is similar to system_wq but for work items which
 * require WQ_HIGHPRI.
 *
 * system_long_wq is similar to system_wq but may host long running
 * works.  Queue flushing might take relatively long.
 *
 * system_unbound_wq is unbound workqueue.  Workers are not bound to
 * any specific CPU, not concurrency managed, and all queued works are
 * executed immediately as long as max_active limit is not reached and
 * resources are available.
 *
 * system_freezable_wq is equivalent to system_wq except that it's
 * freezable.
 *
 * *_power_efficient_wq are inclined towards saving power and converted
 * into WQ_UNBOUND variants if 'wq_power_efficient' is enabled; otherwise,
 * they are same as their non-power-efficient counterparts - e.g.
 * system_power_efficient_wq is identical to system_wq if
 * 'wq_power_efficient' is disabled.  See WQ_POWER_EFFICIENT for more info.
 */

extern struct workqueue_struct *system_wq;
extern struct workqueue_struct *system_highpri_wq;
extern struct workqueue_struct *system_long_wq;
extern struct workqueue_struct *system_unbound_wq;
extern struct workqueue_struct *system_freezable_wq;
extern struct workqueue_struct *system_power_efficient_wq;
extern struct workqueue_struct *system_freezable_power_efficient_wq;

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
int __init workqueue_init_early(void)
{
    ...    
    system_wq = alloc_workqueue("events", 0, 0);
    system_highpri_wq = alloc_workqueue("events_highpri", WQ_HIGHPRI, 0);                           
    system_long_wq = alloc_workqueue("events_long", 0, 0);
    system_unbound_wq = alloc_workqueue("events_unbound", WQ_UNBOUND,
                                            WQ_UNBOUND_MAX_ACTIVE);
    system_freezable_wq = alloc_workqueue("events_freezable",
                                              WQ_FREEZABLE, 0);
    system_power_efficient_wq = alloc_workqueue("events_power_efficient",
                                              WQ_POWER_EFFICIENT, 0);
    system_freezable_power_efficient_wq = alloc_workqueue("events_freezable_power_efficient",
                                              WQ_FREEZABLE | WQ_POWER_EFFICIENT,
                                              0);
    ...
}

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
/**
 * schedule_work - put work task in global workqueue
 * @work: job to be done
 *
 * Returns %false if @work was already on the kernel-global workqueue and
 * %true otherwise.
 *
 * This puts a job in the kernel-global workqueue if it was not already
 * queued and leaves it in the same position on the kernel-global
 * workqueue otherwise.
 */

static inline bool schedule_work(struct work_struct *work){   
    return queue_work(system_wq, work);
}

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

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

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

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

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

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

驱动程序

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

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

创建驱动程序源文件和 Makefile

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ cd tmp/linux-4.15/drivers
$ mkdir my_driver_interrupt_wq
$ touch my_driver_interrupt_wq.c
$ touch Makefile
示例代码全貌

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/interrupt.h>

static int irq;					
static char * devname;		

static struct work_struct mywork;	
			
 // 接收驱动模块加载时传入的参数
module_param(irq, int, 0644);
module_param(devname, charp, 0644);

// 定义驱动程序的 ID,在中断处理函数中用来判断是否需要处理			
#define MY_DEV_ID	   		1226

// 驱动程序数据结构
struct myirq
{
    int devid;
};
 
struct myirq mydev  ={ MY_DEV_ID };

#define KBD_DATA_REG        0x60  
#define KBD_STATUS_REG      0x64
#define KBD_SCANCODE_MASK   0x7f
#define KBD_STATUS_MASK     0x80

// 工作项绑定的处理函数
static void mywork_handler(struct work_struct *work)
{
    printk("mywork_handler is called. \n");
    // do some other things
}
		
//中断处理函数
static irqreturn_t myirq_handler(int irq, void * dev)
{
    struct myirq mydev;
    unsigned char key_code;
    mydev = *(struct myirq*)dev;	
	
	// 检查设备 id,只有当相等的时候才需要处理
	if (MY_DEV_ID == mydev.devid)
	{
		// 读取键盘扫描码
		key_code = inb(KBD_DATA_REG);
	
		if (key_code == 0x01)
		{
			printk("ESC key is pressed! \n");
			
			// 初始化工作项
			INIT_WORK(&mywork, mywork_handler);
			
			// 加入到工作队列 system_wq
        	        schedule_work(&mywork);
		}
	}	

	return IRQ_HANDLED;
}
 
// 驱动模块初始化函数
static int __init myirq_init(void)
{
    printk("myirq_init is called. \n");

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

    printk("register irq[%d] handler success. \n", irq);
    return 0;
}
 
// 驱动模块退出函数
static void __exit myirq_exit(void)
{
    printk("myirq_exit is called. \n");

	// 释放中断处理函数
    free_irq(irq, &mydev);
}
 
MODULE_LICENSE("GPL");
module_init(myirq_init);
module_exit(myirq_exit);
Makefile 文件
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
ifneq ($(KERNELRELEASE),)
	obj-m := my_driver_interrupt_wq.o
else
	KERNELDIR ?= /lib/modules/$(shell uname -r)/build
	PWD := $(shell pwd)
default:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
clean:
	$(MAKE) -C $(KERNEL_PATH) M=$(PWD) clean
endif

编译、测试

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ make
$ sudo insmod my_driver_interrupt_wq.ko irq=1 devname=mydev

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ lsmod | grep my_driver_interrupt_wq
my_driver_interrupt_wq    16384  0

再看一下 dmesg 的输出信息:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ dmesg
...
[  188.247636] myirq_init is called. 
[  188.247642] register irq[1] handler success.

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

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

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
if (key_code == 0x01)
{
	printk("ESC key is pressed! \n");
	INIT_WORK(&mywork, mywork_handler);
	schedule_work(&mywork);
}

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[  305.053155] ESC key is pressed! 
[  305.053177] mywork_handler is called.

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

完美!

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-12-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 IOT物联网小镇 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Node.js 调试一路走来经历了什么
做为前端开发,想必大家都写过 Node.js 的代码,也大概率用 debugger 断点调试过。
神说要有光zxg
2022/06/06
6490
Node.js 调试一路走来经历了什么
Linux C/C++ 编程环境搭建
GCC:默认将.c文件视为C程序,.cpp文件需手动指定为C++(如gcc -xc++);默认链接C标准库(libc),编译C++程序需手动添加-lstdc++参数。‌
麦克马
2025/05/07
1970
Linux C/C++ 编程环境搭建
vscode调试Node.js指南
前言:调试代码不管对于开发还是学习源码都是非常重要的技能,本文简单介绍vscode调试Node.js相关代码的调试技巧。
theanarkh
2021/09/16
5.7K0
vscode调试Node.js指南
使用 Chrome Devtools 调试您的 Node.js 程序
俗话说:“工欲善其事,必先利其器”,调试是每一个开发人员都要遇到的问题,选择一个合适的调试工具也尤为重要。 在 Node.js 开发过程中除了万能的 console.log 之外,本节介绍一个 Node.js 与 Chrome Devtools 结合的调试工具,以后你可以选择使用浏览器来调试 Node.js 应用程序了。
五月君
2020/12/30
3.3K0
使用 Chrome Devtools 调试您的 Node.js 程序
【点滴】用 Chrome DevTools 调试 Node.js
从 v 6.3.0 开始,可以用 Chrome Developer Tools 调试 Node.js。以下是操作步骤:
疯狂的技术宅
2021/03/16
3.6K0
Node 调试工具入门教程
JavaScript 程序越来越复杂,调试工具的重要性日益凸显。客户端脚本有浏览器,Node 脚本怎么调试呢? 2016年,Node 决定将 Chrome 浏览器的"开发者工具"作为官方的调试工具,使
ruanyf
2018/04/12
8710
Node 调试工具入门教程
CmakeList的编写和参数详解
在linux 下进行开发很多人选择编写makefile 文件进行项目环境搭建,而makefile 文件依赖关系复杂,工作量很大,搞的人头很大。采用自动化的项目构建工具cmake 可以将程序员从复杂的makefile 文件中解脱出来。cmake 根据内置的规则和语法来自动生成相关的makefile 文件进行编译,同时还支持静态库和动态库的构建,我把工作中用到的东东总结在此,方便忘记时随时查看,具体cmake的介绍和详细语法还是参考官方文档(http://www.cmake.org/),有一篇中文的cmake 实践 写的不错,可以google一下。
全栈程序员站长
2022/11/15
2.3K0
envoy vscode调试环境搭建
经过一周的反复折腾,终于能顺利 debug envoy 源码,中途踩了无数坑,在此记录一下。
kinnylee
2021/12/06
2.8K0
【保姆级】前端使用node.js基础教程
Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境,常用于服务器端编程。以下是一些 Node.js 中常用的命令:
肥晨
2024/03/22
2710
方便快捷的调试 Node.js 程序
在调试程序时总是会遇到各种挑战。Node.js 的异步工作流为这一艰巨的过程增加了额外的复杂性。尽管 V8 引擎为了方便访问异步栈跟踪进行了一些更新,但是在很多数情况下,我们只会在程序主线程上遇到错误,这使得调试有些困难。同样,当我们的 Node.js 程序崩溃时,通常需要依靠一些复杂的 CLI 工具来分析核心转储[1]。
疯狂的技术宅
2020/08/19
1.7K0
调试 node.js 程序
在程序开发中,如何快速的查找定位问题是一项非常重要的基本功。在实际开发过程中,或多或少都会遇到程序出现问题导致无法正常运行的情况,因此,调试代码就变成了一项无法避免的工作。这里简单介绍下如何调试 node.js 程序。
用户6167509
2020/04/08
3.1K0
使用CEF(五)— 在QT中集成CEF(2)基于CLion与CMake搭建环境
在前文《使用CEF(四)— 在QT中集成CEF(1):基本集成》中,我们使用VS+QT的插件搭建了一个基于QT+CEF的项目。时过境迁,笔者目前用的最多的就是CLion+CMake搭建C/C项目,并且CLion提供了对C/C强大的开发环境。此外,也想将CMake搭建QT项目作为一次实践,故由此文。
w4ngzhen
2023/10/17
1.2K0
使用CEF(五)— 在QT中集成CEF(2)基于CLion与CMake搭建环境
Node.js命令介绍
Node.js是一个基于Chrome的V8引擎的JavaScript运行环境,它允许开发者在服务器端运行JavaScript代码。Node.js的强大之处在于其非阻塞I/O模型和事件驱动架构,使其轻量级且高效,尤其适用于数据密集型实时应用。在Node.js中,我们可以通过命令行工具来执行各种操作,下面我将介绍一些常用的Node.js命令。
china马斯克
2024/07/27
1640
Android NDK 开发 | CMake 使用手册 - 初见篇
之前写过一篇 《[-NDK 导引篇 -] 在NDK开发之前你应知道的东西》 介绍了在进入 NDK 学习之前,如何摆正自己的角色。时隔两年,NDK 系列文章开始填坑,在上一篇 《 NDK 是什么 | FFmpeg 5.0 编译 so 库》 中,介绍了 NDK 的概念,以及其作用。
张风捷特烈
2022/09/20
1.4K0
Android NDK 开发 | CMake 使用手册 - 初见篇
为你揭开 node.js 调试面纱
最近在写公司内部的一个 node 应用的时候,发现自己在 node 调试这块还是比较薄弱的,特意恶补了一下,在这里也做一下分享。
coder_koala
2019/12/06
1.2K0
为你揭开 node.js 调试面纱
Node.js 项目调试指南
Node.js 是一种流行的 JavaScript 运行时,与谷歌 Chrome 浏览器使用相同的 V8 引擎。它是跨平台的,在创建 Web 服务器、构建工具、命令行工具等方面越来越受欢迎。
ConardLi
2023/08/23
9730
Node.js 项目调试指南
2019-01-16 Ubuntu/Linux 用vscode 运行/调试 c++ 程序
参考文章 Ubuntu/Linux 用vscode 运行/调试 c++ 程序在ubuntu上搭建vscode的开发环境,出现了几个问题,这里记录一下:
oracle3
2022/05/13
5810
一篇极度舒适的OpenGL_ES环境搭建(Ubuntu 18.04 LTS)
github传送门 ---- 目录 前言 PowerVR CMake环境 FreeImage CMakeLists.txt解析 源码 最后 ---- 前言 作为一个梦想成为游戏制作人的菜鸟程序员, 我终究没悬念地踏上了撰写shader的道路(手动滑稽). 这是一篇比较细致的Ubuntu18.04下OpenGL_ES环境搭建的文件, 也是我爬过n多个坑之后的总结, 希望能帮助到Mac背后的你(手动滑稽). ---- PowerVR 模拟器方面, 我选择PowerVR, 当然, 你可以选择别的, 来到官
sean_yang
2020/02/18
2.7K0
一篇极度舒适的OpenGL_ES环境搭建(Ubuntu 18.04 LTS)
了不起的 Deno 入门篇
Deno 是一个 JavaScript/TypeScript 的运行时,默认使用安全环境执行代码,有着卓越的开发体验。Deno 含有以下功能亮点:
阿宝哥
2020/05/25
3.4K0
了不起的 Deno 入门篇
使用vscode调试你的node应用
从一开始使用 webstorm 内置的 debug 功能, 到使用node-inspector库进行调试顺便脱离 webstorm 的笨重, 再后来 nodejs 内置了debugger 模块也可以帮助调试我们的应用.
funkyLover
2019/05/24
2.7K0
相关推荐
Node.js 调试一路走来经历了什么
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验