理解Linux內核搶占模型（最透徹一篇）

時間：2020-05-15 10:11:00

關鍵字： Linux 內核代碼

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]用案例讓你深入理解3個搶占模型的區(qū)別。

本文原文地址：

https://devarea.com/understanding-linux-kernel-preemption/#.XrKLcfnx05k

作者：Liran B.H

譯者：宋寶華

當配置Linux內核的時候，我們可以選擇一些參數(shù)，這些參數(shù)能影響系統(tǒng)的行為。你可以用不同的優(yōu)先級、調度類和搶占模型來工作。正確地選擇這些參數(shù)是非常重要的。

本文將論述不同的搶占模型如何影響用戶和系統(tǒng)的行為。

當你使用 make menuconfig配置內核的時候，你能看到這樣的菜單：

為了深入理解這三個搶占模型的區(qū)別，我們將寫一個案例：

如果低優(yōu)先級的線程陷入系統(tǒng)調用，高優(yōu)先級的線程睡眠到期，究竟會發(fā)生什么？下面我們來一種模型一種模型地看。

這種情況下，上下文切換發(fā)生在系統(tǒng)調用返回用戶空間的點。案例如下：

內核代碼，簡單的字符設備：

讀里面delay了5秒，注意mdelay是一個計算型的busy-loop。

用戶空間代碼如下：

實驗步驟：

這種情況內核里面也可以搶占，意味著上述程序里面的高優(yōu)先級線程3秒后可醒來。

這種情況下，系統(tǒng)會有更多的上下文切換，但是實時性更加好。對于要求軟實時的嵌入式系統(tǒng)而言，這個選項是最佳的。但是對于服務器而言，通常第一個選項更好——更少的上下文切換，更多的CPU時間用作有用功。

運行結果（stop、start時間差3秒）：

Voluntary Kernel Preemption

這種情況和第一種情況"no forced preemption"類似，但是內核開發(fā)者可以在進行復雜操作的時候，時不時檢查一下是否可以reschedule。他們可以調用might_resched()函數(shù)。

在下面的代碼中，我們添加了一些檢查點（check point）

如果我們把might_resched()注釋掉，它會delay 7秒。

添加cond_resched()調用將導致系統(tǒng)檢查是否有高優(yōu)先級的任務被喚醒，這樣高優(yōu)先級任務5秒可以醒來（其中1秒在systemcall之前，另外4秒在kernel）。

運行結果：

如果我們使能RT補丁，我們會得到一個硬實時的kernel。這意味著任何代碼可以搶占任何人。比如一個更加緊急的任務可以搶占中斷服務程序ISR。這個patch進行了如下改動：

打補丁后會看到2個新增的菜單：

其中 “Preemptible Kernel (Basic RT)” 是為了調試目的的，為了全面使用RT補丁的功能，我們應該選擇最后一項 – Fully Preemptible Kernel。這樣我們會有更多的上下文切換，但是可以滿足RT的實時要求。

免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！