disable_local_irq和內核定時器

Question

嗨，大家好， 雖然做了一些我們的驅動器（上 PowerPC的目標）SMP移植我們觀察到一些行爲上，我需要你們 一些啓發：

1. 在在UP系統上執行local_irq_disable（），jiffies往往會凍結，即計數停止遞增。這是預期的嗎？我認爲 減法器中斷是'內部'，並且不應得到 受local_irq_disable類型調用影響，因爲我期望它到 禁用本地IRQ中斷處理（外部中斷）。 系統當然凍結，然後也做了local_irq_enable（）012ffjiffies計數跳轉，它似乎是補償local_irq_disable（）和enable（）調用之間的'時間 失效'。

2. 在SMP系統（帶2個e500核心的P2020）上做同樣的工作， 的結果令人驚訝。首先，插入到 的模塊會執行此測試，並始終在覈心1上執行。此外，有時候 沒有看到「jiffies」計數器的凍結，有時我們發現它確實凍結。再次在計數凍結的情況下，在執行local_irq_enable（）之後，它傾向於跳轉 。我不知道爲什麼這可能是 發生。 我們知道在SMP的情況下兩個內核是否都運行計劃計時器，因此 在某些情況下，我們看不到jiffie計數的凍結，或者僅在覈心0上顯示爲 ？

此外，由於內核定時器依靠「jiffies的」 - 這將意味着 沒有我們的內核定時器將火如果local_irq_disable（）一直 做了什麼？在一個 SMP系統中的核心之一將會怎樣？

還有許多其他的問題，但我想這些就足以 在一般性討論開始差不多:)

TIA

NS從所做的實驗

一些更多評論。我在這個時間點的理解是，由於內核定時器依賴'jiffies'來觸發，所以當我發出local_irq_save（）時，它們實際上不會在UP系統上觸發。事實上，我們的一些代碼是基於這樣一個假設，即當我發出local_irq_save（）時，它確保可以保護本地處理器和內核定時器的中斷。

但是在SMP系統上執行同樣的實驗，即使兩個內核都執行local_irq_save（），jiffies也不會停止遞增，系統也不會凍結。這怎麼可能 ？ LINUX是否使用其他機制觸發SMP系統中的定時器中斷或可能使用IPI？這也破壞了我們的假設，即local_irq_disable將保護系統免受至少在同一核心上運行的內核定時器的影響。

我們該如何編寫一個安全的異步事件代碼，即中斷和內核定時器，並且對於UP和SMP都是有效的。

Answer 1

local_irq_disable僅禁用當前內核中的中斷，因此，當您是單核時，所有內容都被禁用（包括定時器中斷），這就是jiffies未更新的原因。 在SMP上運行時，有時候您會在更新jiffies的核心上禁用中斷，有時不會。 這通常不是問題，因爲中斷應該只在非常短的時間內被禁用，並且所有預定的定時器將在中斷再次啓用後觸發。

你怎麼知道你的模塊總是在覈心1上運行？在當前版本的內核中，它甚至可能同時運行在多個內核上（也就是說，如果你不強迫它不這樣做的話）。

Answer 2

這個問題有幾個方面。讓我們他們1由1

1.

一個）

local_irq_save（）簡單地清除EFLAGS的IF標誌寄存器。 IRQ處理程序可以在其他內核上一致運行。

global_irq_save（）不可用，因爲這需要處理器間的通信來實現，因爲本地irq禁用僅用於很短的時間，所以它不是真正需要的。

B）

現代APICS允許本內核，內核基本上是程序所必需的寄存器中和除了極少數例外IRQ動態分配獲得的IRQ的循環分配。

這樣做的結果是，如果irqs在本地足夠長的時間內被禁用，當APIC向核心發送一個IRQ並將其禁用時，最終結果將是系統將全局停止接收此特定IRQ，直到irqs最終在接收到該類型的最後一個IRQ的核心上本地重新啓用的點。

2.

關於有關jiffies的更新和IRQ禁用了不同的結果，這取決於所選擇的clocksource。

你可以計算出哪一個是通過諮詢choosen：

$貓/ SYS /設備/系統/ clocksource/clocksource0/current_clocksource

，如果你有TSC作爲clocksource那麼所有的核心都在本地。但是，如果你的clocksource是其他的東西，例如：HPET外部設備，那麼由於第一點中所述的原因，jiffies將會被凍結。