Linuxカーネルについて2つの質問があります。具体的には、Linuxがタイマー割り込みで何をするのかを正確に知っている人はいますか?これに関するドキュメントはありますか?また、カーネルを構築するときにCONFIG_HZ設定を変更すると、何が影響を受けますか?
前もって感謝します!
Linuxタイマー割り込みハンドラーはそれほど多くのことをしません直接。 x86の場合、デフォルトのPIT/HPETタイマー割り込みハンドラーがあります in Arch/x86/kernel/time.c
:
static irqreturn_t timer_interrupt(int irq, void *dev_id)
{
global_clock_event->event_handler(global_clock_event);
return IRQ_HANDLED;
}
これにより、グローバルクロックイベントのイベントハンドラーが呼び出されます tick_handler_periodic
デフォルトでは、 jiffiesカウンターを更新します 、グローバル負荷を計算し、時間が追跡される他のいくつかの場所を更新します。
発生する割り込みの副作用として、 __schedule
が呼び出される可能性があるため、タイマー割り込みも(他の割り込みと同様に)タスク切り替えにつながる可能性があります。
CONFIG_HZ を変更すると、タイマー割り込みの周期が変更されます。 HZ
を増やすと、起動頻度が高くなるため、タイマー関連のオーバーヘッドは増えますが、タスクのスケジューリングがしばらく待つ機会は少なくなります(したがって、対話性が向上します)。 HZ
を減らすと、起動頻度が少なくなるため、タイマー関連のオーバーヘッドは少なくなりますが、タスクがスケジュールされるのを待つリスクが高くなります(したがって、インタラクティブな応答性を犠牲にしてスループットが向上します)。いつものように、最良の妥協点は特定のワークロードによって異なります。最近はCONFIG_HZ
とにかく、スケジューリングの側面にはあまり関係がありません。 Linux CPUスケジューラで使用されるタイムスライスの長さを変更するにはどうすればよいですか? を参照してください。
linuxは何をしますかinタイマー割り込み?
私はこれを中間の行動を求めるものととらえています。
その__schedule()
からコピーします:
* 3. Wakeups don't really cause entry into schedule(). They add a
* task to the run-queue and that's it.
*
* Now, if the new task added to the run-queue preempts the current
* task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets
* called on the nearest possible occasion:
これは良い出発点です。それは十分に文書化されています。これが長い物語の始まりです。 「ウェイクアップ」とは何ですか?それはRとSの状態についてですか?とブロッキング?
S.K.の回答と、リンクの1つに対して、HZが「もはやそれほど重要ではない」というわずかな異議が1つだけあります。
過去に混乱があったためか、100HZから1000HZに、そして300HZに戻って、同時に「マルチメディア」に合わせるための過剰補正があった可能性があります(HPET Origin 2005:「マルチメディアタイマー」を考えてみてください)。
4つ以上のコアを使用することもできますが、それほど重要ではありません。ただし、「サーバー」で何をしたいかによっては、それでも問題になるはずです。この遅延とスループットのトレードオフは、高負荷の下で重要になる可能性があります。
また、タイマー割り込みでスケジューリングが行われない場合は、これらの「その他」の割り込みでスケジューリングが行われます。
また、HZを構成できないのはなぜですか(ブートまたはランタイム)?