今日この記事を読んだよりしかし、私は割り込みに関するトピックをまったく理解していないので、知識のある誰かが過去にこのデーモンを使用していた理由と、現在推奨されている理由を説明することをお勧めします。
ベストアンサー1
私のものより問題は、これが過去/現在、現代対古代制度の問題ではないという点だ。これはもっと興味があります。システム、ワークロード、最適化する項目について知っている情報（待機時間とスループット）知っているほど、ヘルパーは問題を台無しにしたくないでしょう。わからないあなたのシステムを制御し、あなたに代わって決定を下します。 (*1)
起動時に、割り込みは通常CPU間で均等に（数ベース）共有されます。 （つまり、実行時に発生する頻度とハンドラが完了するのにかかるCPU時間に関係なく）。スケジュールと作業量によっては、望ましくない遅延が発生する可能性があります。
たとえば、2つのPCIサウンドカードがあり、どちらも非常に制限されたバッファ（待機時間を短縮するため）を使用して96KHzのサンプリングレートで並列に使用され、一部のUSB-MIDIハードウェアが追加されました。 （* 2）
この場合、私はirq共有を避けるために最善を尽くしました（他のデバイスは同じIRQを使用します）、3つの関連するirq（各デバイスに1つずつ）が同じCPUにあることは間違いありません。そして、可能であれば、Ardorが使用するCPUではありません...単に理由は次のとおりです。
- どちらも同じ重要性を持っているため、IRQスレッドは同じリアルタイム優先順位で実行されるため、他のIRQの処理中に発生するすべての割り込み処理が遅くなり、レイテンシが増えます（悪くない場合でも）：XRUNS（バッファオーバーフローによるサンプルは廃棄されました。）
- これらの割り込みを処理するために必要なコードとデータ構造は、プロセッサのデータキャッシュと命令キャッシュにある可能性が最も低く、割り込みが処理されるたびに追加の待ち時間が発生します。
irqbalanceデーモンは次のことができます。おそらくしばらくすると、ある時点で初期設定が最適ではないという事実が発見され（実行時に）IRQピンを（費用がかかる）再構成することに決めました（おそらくMIDIキーボードの使用を中断した場合は逆になりますか？）うーん。 ..可能！
しかし、これらすべてを念頭に置いて、私自身はこれら3つのIRQのそれぞれのためのCPUを一気に分離し、4番目のIRQが他のすべてを処理するようにします。 （もちろんこれ以上できません...私はコアIIを実行しています;-）そして... irqbalanceデーモン：HandsOFF、私が何をしているのか知っています！
代わりに、irqbalanceデーモンに対する同じ決定につながるので、私がCPUバインディングジョブのスループットにのみ興味があることがわかった場合は、すべてのirqを1つに固定する必要があります。家庭CPUを使用し、他のすべてのCPUが干渉なくワークロードを共有できるようにします。
そして、自分のシステムがすべてのことをより良くすることを期待する経験がない、いわゆる「一般的なデスクトップユーザー」もあります。信じる低レベルのソフトウェアの考慮事項を心配することなく、最高のランタイム条件を提供します。 （失礼な意図はありません。私は時々（しかしまれに）そのようなことが起こります。）
この場合、irqbalanceデーモンを実行すると時々（そしてコストがかかるので）待ち時間を減らすのに役立ちますが、確かにわからない方法。
とにかく、8コアシステムで48Kz / 60fpsビデオを見てEメールに返信したときに誰が気づいたのですか？ところで、これがおそらくirqbalanceデーモンの関心を現代性と関連付けることができる理由でしょう。近代化するほど、より多くのCPUを持ち、周波数が高くなるほど、CPUの固定について心配する必要が少なくなります。
免責事項：（* 3）
それでは、IRQ管理についてもっと技術的に見てみましょう。
Linuxでは、IRQ（またはMSI）が発生したときに必要なタスクを実行するために割り込みを処理する2つの方法があります。
古い伝統的な方法: IRQ ハンドラの一部として、すべてのタスクをカーネル空間に実装します。これは可能な限り最高のスループットを達成しますが、実行中のタスク（非常に重要である可能性があります）を不快に中断し、処理全体で他の、おそらくより重要なIRQをマスクします。
ライブシステムでは確かにこれはしたくありません。スレッドIRQ法：IRQハンドラの一部として最小限の操作を実行します。実装する必要があるのは、すべての割り込みをマスクし、ほとんどのタスクをSCHED_RR（優先順位が最も高いとき）を予約するカーネルスレッドが実行するようにすることです。
もちろん、少なくとも2つの追加のコンテキスト切り替えが必要なため、処理時間が長くなりますが、これはもちろん、相対的な優先順位（タスク間、IRQハンドラ間、タスクとIRQハンドラ時間の間）が実際に重要なリアルタイムシステムに好ましい方法です。重要。
このスレッドIRQコンテキストでは、irqスレッドはデフォルトでIRQを処理するCPUに固定されています。ただし、実行時のロードに関する考慮事項に応じて、スケジューラはアイドル時間がある場合は別のCPUでカーネルスレッドを再スケジュールすることを決定できます。 (*4)
したがって、2020年初めからスレッドのirqコンテキストで、一部のデーモンがIRQハンドラを変更するように（リアルタイムで、高価な）ことは明らかに（客観的に）非生産的です。即時ワークロードの共有を考慮して、最高のものが何であるかをスケジューラに決定させてください。
*1：GPSを考えてみてください。右折してください！海峡で！まあ、振り返って！
*2：一般的なライブ公演DAW（少なくとも私：-P）
*3：この回答はコメントに基づいて理解することができます。私は実行時にシステムを構成するのが嫌だという事実を正直に隠すことはありません。彼らのいたずらが私の意志と一致するふりをするなら、私はそれらをさらに憎む。
*4：これは2020年初めから可能でした。ジョン・ゲイリーのパッチ。