立你斯學習記錄

今天在“top”發現一個events/0行程CPU資源佔很高。
如下所示

top - 14:31:02 up 14 min,  3 users,  load average: 1.61, 0.78, 0.42
Tasks: 167 total,   1 running, 166 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.6%us, 26.1%sy,  0.0%ni, 61.6%id,  0.0%wa,  7.8%hi,  2.0%si,  0.0%st
Mem:   1799980k total,   599020k used,  1200960k free,    62808k buffers
Swap:   860152k total,        0k used,   860152k free,   312400k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    9 root      20   0     0    0    0 S   44  0.0   0:04.01 events/0
  723 syslog    20   0 35560 1896 1040 S   20  0.1   0:10.70 rsyslogd
 1103 root      20   0 45328  16m 8516 S   15  0.9   0:24.77 Xorg
 3071 kenneth   20   0 91996  46m  29m S   11  2.6   0:02.43 vlc
 1254 kenneth   20   0 40796  14m  10m S    5  0.8   0:01.04 gnome-panel
 1387 kenneth   20   0 49620  13m  10m S    5  0.8   0:00.26 clock-applet
 1477 root      20   0  8664 1688 1140 S    3  0.1   0:00.40 nmbd
 3069 root      20   0  2548 1212  904 R    1  0.1   0:00.26 top
 1255 kenneth   20   0 53464  23m 7768 S    0  1.3   0:03.79 compiz
    1 root      20   0  2812 1644 1192 S    0  0.1   0:00.43 init
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd

網上貌似很少對它的描述，總結一下《Linux內核設計與實現》中的內容（page87）。

我們都知道中斷的底半部機制有三種：軟中斷、tasklet和工作隊列。其中軟中斷很少使用，內核中只有網路在使用，它的延時是最小的。

tasklet是軟中斷的一個應用，所有執行緒註冊的tasklet都會順序被執行。因此tasklet的執行環境是軟中斷上下文，所以不能阻塞或者睡眠。一般情況下，tasklet的延遲也很小，可以滿足大部分需求。

要是底半部中可能睡眠，那麼只好使用工作隊列了。工作隊列其實是把要做的底半部的函數交給內核的專門執行緒去調用。這樣工作隊列就運行於執行緒環境了， 不怕睡眠。當然，睡眠會影響註冊到同一執行緒的其它底半部的執行，但不會引起大的問題。每個CPU都有一個執行緒（events/n,n是編號）負責執行工作 佇列，第一個CPU的執行緒是events/0，如果是雙核的，還會有一個events/1執行緒。

我的程式使用了工作隊列，所以每次執行都會多出一個events/0(第一個CPU上工作執行緒)。

而我在 工作隊列 呼叫的函示裡面有udelay() 去等待硬體執行完成..

在Ｌinux　Ｄriver開發中，經常要用到延遲函數：msleep，mdelay／udelay．

雖然msleep和mdelay都有延遲的作用，但他們是有區別的．

mdeday還忙等待函數，在延遲過程中無法運行其他任務．這個延遲的時間是準確的．是需要等待多少時間就會真正等待多少時間．而msleep是休 眠函數，它不涉及忙等待．你如果是msleep(１０)，那實際上延遲的時間，大部分時候是要多於１０ms的，是個不定的時間值．

所以應該改用 msleep ... 或用信號量 去等硬體做完