目錄

· 工作隊列是什么

· 驅(qū)動程序

· 編譯、測試

別人的經(jīng)驗，我們的階梯！

大家好，我是道哥，今天我為大伙兒解說的技術(shù)知識點是：【中斷處理中的下半部分機制－工作隊列】。

在剛開始介紹中斷處理的時候，曾經(jīng)貼出下面這張圖：

圖中描述了中斷處理中的下半部分都有哪些機制，以及如何根據(jù)實際的業(yè)務場景、限制條件來進行選擇。

可以看出：這些不同的實現(xiàn)之間，有些是重復的，或者是相互取代的關(guān)系。

也正因為此，它們之間的使用方式幾乎是大同小異，至少是在API接口函數(shù)的使用方式上，從使用這的角度來看，都是非常類似的。

這篇文章，我們就通過實際的代碼操作，來演示一下工作隊列（workqueue）的使用方式。

工作隊列是什么

工作隊列是Linux操作系統(tǒng)中，進行中斷下半部分處理的重要方式！

從名稱上可以猜到：一個工作隊列就好像業(yè)務層常用的消息隊列一樣，里面存放著很多的工作項等待著被處理。

工作隊列中有兩個重要的結(jié)構(gòu)體：工作隊列（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；   ／／ 指向處理函數(shù)

＃ifdef CONFIG＿LOCKDEP                                                                                  
           struct lockdep＿map lockdep＿map；

＃endif

｝；

在內(nèi)核中，工作隊列中的所有工作項，是通過鏈表串在一起的，并且等待著操作系統(tǒng)中的某個線程挨個取出來處理。

這些線程，可以是由驅(qū)動程序通過 kthread＿create 創(chuàng)建的線程，也可以是由操作系統(tǒng)預先就創(chuàng)建好的線程。

這里就涉及到一個取舍的問題了。

如果我們的處理函數(shù)很簡單，那么就沒有必要創(chuàng)建一個單獨的線程來處理了。

原因有二：

1．創(chuàng)建一個內(nèi)核線程是很耗費資源的，如果函數(shù)很簡單，很快執(zhí)行結(jié)束之后再關(guān)閉線程，太劃不來了，得不償失；

2．如果每一個驅(qū)動程序編寫者都毫無節(jié)制地創(chuàng)建內(nèi)核線程，那么內(nèi)核中將會存在大量不必要的線程，當然了本質(zhì)上還是系統(tǒng)資源消耗和執(zhí)行效率的問題；

為了避免這種情況，于是操作系統(tǒng)就為我們預先創(chuàng)建好一些工作隊列和內(nèi)核線程。

我們只需要把需要處理的工作項，直接添加到這些預先創(chuàng)建好的工作隊列中就可以了，它們就會被相應的內(nèi)核線程取出來處理。

例如下面這些工作隊列，就是內(nèi)核默認創(chuàng)建的（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；

以上這些默認工作隊列的創(chuàng)建代碼是（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 被使用的頻率很高，于是內(nèi)核就封裝了一個簡單的函數(shù)（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）；

｝

當然了，任何事情有利就有弊！

由于內(nèi)核默認創(chuàng)建的工作隊列，是被所有的驅(qū)動程序共享的。

如果所有的驅(qū)動程序都把等待處理的工作項委托給它們來處理，那么就會導致某個工作隊列中過于擁擠。

根據(jù)先來后到的原則，工作隊列中后加入的工作項，就可能因為前面工作項的處理函數(shù)執(zhí)行的時間太長，從而導致時效性無法保證。

因此，這里存在一個系統(tǒng)平衡的問題。

關(guān)于工作隊列的基本知識點就介紹到這里，下面來實際操作驗證一下。

驅(qū)動程序

之前的幾篇文章，在驅(qū)動程序中測試中斷處理的操作流程都是一樣的，因此這里就不在操作流程上進行贅述了。

這里直接給出驅(qū)動程序的全貌代碼，然后查看 dmesg 的輸出信息。

創(chuàng)建驅(qū)動程序源文件和 Makefile：

＄ cd tmp／linux－4．15／drivers

＄ mkdir my＿driver＿interrupt＿wq

＄ touch my＿driver＿interrupt＿wq．c

＄ touch Makefile

示例代碼全貌

測試場景是：加載驅(qū)動模塊之后，如果監(jiān)測到鍵盤上的ESC鍵被按下，那么就往內(nèi)核默認的工作隊列system＿wq中增加一個工作項，然后觀察該工作項對應的處理函數(shù)是否被調(diào)用。

＃include ＜linux／kernel．h＞

＃include ＜linux／module．h＞

＃include ＜linux／interrupt．h＞

static int irq；

static char ＊ devname；

static struct work＿struct mywork；

／／ 接收驅(qū)動模塊加載時傳入的參數(shù)

module＿param（irq， int， 0644）；

module＿param（devname， charp， 0644）；

／／ 定義驅(qū)動程序的 ID，在中斷處理函數(shù)中用來判斷是否需要處理

＃define MY＿DEV＿ID   1226

／／ 驅(qū)動程序數(shù)據(jù)結(jié)構(gòu)

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

／／ 工作項綁定的處理函數(shù)

static void mywork＿handler（struct work＿struct ＊work）

｛

printk（＂mywork＿handler is called． ＂）；

    ／／ do some other things

｝

／／中斷處理函數(shù)

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；

｝

／／ 驅(qū)動模塊初始化函數(shù)

static int ＿＿init myirq＿init（void）

｛

       printk（＂myirq＿init is called． ＂）；

          ／／ 注冊中斷處理函數(shù)

       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；
        ｝

／／ 驅(qū)動模塊退出函數(shù)

static void ＿＿exit myirq＿exit（void）

｛
             printk（＂myirq＿exit is called． ＂）；
                  ／／ 釋放中斷處理函數(shù)
             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

檢查驅(qū)動模塊是否加載成功：

＄ 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．

說明：驅(qū)動程序的初始化函數(shù) myirq＿init 被調(diào)用了，并且成功注冊了 1 號中斷的處理程序。

此時，按一下鍵盤上的 ESC 鍵。

操作系統(tǒng)在捕獲到鍵盤中斷之后，會依次調(diào)用此中斷的所有中斷處理程序，其中就包括我們注冊的 myirq＿handler 函數(shù)。

在這個函數(shù)中，當判斷出是ESC按鍵時，就初始化一個工作項（把結(jié)構(gòu)體 work＿struct 類型的變量與一個處理函數(shù)綁定起來），然后丟給操作系統(tǒng)預先創(chuàng)建好的工作隊列（system＿wq）去處理，如下所示：

if （key＿code ＝＝ 0x01）

｛

       printk（＂ESC key is pressed！ ＂）；

       INIT＿WORK（＆mywork， mywork＿handler）；

       schedule＿work（＆mywork）；

｝

因此，當相應的內(nèi)核線程從這個工作隊列（system＿wq）中取出工作項（mywork）來處理的時候，函數(shù) mywork＿handler 就會被調(diào)用。

現(xiàn)在來看一下 dmesg 的輸出信息：

［  305．053155］ ESC key is pressed！

［  305．053177］ mywork＿handler is called．

可以看到：mywork＿handler函數(shù)被正確調(diào)用了。

完美！