• 发文
  • 评论
  • 微博
  • 空间
  • 微信

linux驱动实践:中断处理中的【工作队列】 workqueue 是什么鬼?-利来app官方下载

道哥分享 2021-12-28 13:49 发文

目录

· 工作队列是什么

· 驱动程序

· 编译、测试

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

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

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

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

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

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

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

工作队列是什么

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

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

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

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
      };

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):

* 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):

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)给我们使用:

/**

* 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:

$ cd tmp/linux-4.15/drivers

$ mkdir my_driver_interrupt_wq

$ touch my_driver_interrupt_wq.c

$ touch makefile

示例代码全貌

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

#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. ");

    // 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! ");

                   // 初始化工作项

                    init_work(&mywork, mywork_handler);

                 // 加入到工作队列 system_wq

                    schedule_work(&mywork);

          }

    }

    return irq_handled;

// 驱动模块初始化函数

static int __init myirq_init(void)

       printk("myirq_init is called. ");

          // 注册中断处理函数

       if(request_irq(irq, myirq_handler, irqf_shared, devname, &mydev)!=0)
            {
                 printk("register irq[%d] handler failed. ", irq);
                 return -1;
              }
                 printk("register irq[%d] handler success. ", irq);
                 return 0;
        }

// 驱动模块退出函数

static void __exit myirq_exit(void)


             printk("myirq_exit is called. ");
                  // 释放中断处理函数
             free_irq(irq, &mydev);

module_license("gpl");

module_init(myirq_init);

module_exit(myirq_exit);

makefile 文件

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

编译、测试

$ make

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

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

$ lsmod | grep my_driver_interrupt_wq

my_driver_interrupt_wq    16384  0

再看一下 dmesg 的输出信息:

$ 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)去处理,如下所示:

if (key_code == 0x01)

       printk("esc key is pressed! ");

       init_work(&mywork, mywork_handler);

       schedule_work(&mywork);

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

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

[  305.053155] esc key is pressed!

[  305.053177] mywork_handler is called.

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

完美!

声明:本文为ofweek维科号作者发布,不代表ofweek维科号立场。如有侵权或其他问题,请及时联系利来国际下载举报。
2
评论
评论

相关阅读

暂无数据

道哥分享

专注嵌入式软件开发,越分享、越幸...

热门文章排行榜
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

举报文章问题

×
  • 营销广告
  • 重复、旧闻
  • 格式问题
  • 低俗
  • 标题夸张
  • 与事实不符
  • 疑似抄袭
  • 我有话要说
确定 取消

举报评论问题

×
  • 淫秽色情
  • 营销广告
  • 恶意攻击谩骂
  • 我要吐槽
确定 取消

用户登录×