web-dev-qa-db-ja.com

コンピュータアーキテクチャ：IRQ範囲が狭いため、USBキーボードの応答性が低下しますか？

これが私が今考えた声明です。誰かがそれが本当かどうか、そしてなぜそれが本当かを教えてもらえますか？

ステートメント：USBキーボードは、より低いIRQレベルにしかアクセスできないUSB汎用ドライバーとアーキテクチャに依存しているため、キーボードにIRQへのアクセスを許可することはできません。別の（たとえばPS2）コントローラーと同じくらい優先度が高い

これは（それが本当なら）USBキーボードが別のポートタイプ（PS2のような）に接続されたキーボードよりも（速度よりも可用性の点で）優先度が低いことを意味しますか？

たとえば、別の中優先度割り込みルーチンでスタックしている障害のあるシステムで、中優先度IRQにマップされたUSBキーボードを取り上げます。優先度が比較的等しいため、キーボードイベントは無視され、Ctrl-Alt-delやその他の緊急キーストロークを送信することはできません。キーボードの優先度が高い場合、システムはキーストローク割り込みルーチンに入る可能性があります。

または、USBコントローラーには、キーボードに必要な優先順位（基本的に停電のすぐ下）を与えるのに十分なIRQ範囲がありますか（優先順位が連​​続しているかどうかは関係ありません）？

また、リモートデスクトップセッションのネットワーク接続を介してマッピングされた仮想キーボードについてはどうでしょうか。

編集：私の質問は速度についてではありません（コメントを参照）：主な質問は：PS2キーボードは、より高い割り込み優先度でどこかにスタックしているCPUと話す機会が多いですか？ USBでキーボードより低い？

usboperating-systemsirq
19
PPC

IRQの範囲ではなく、次の3つの主な要因があります。

  1. バスの混雑量
  2. データ量
  3. データパスの長さ

以前は、キーボードとマウスには専用のIRQ（キーボードの場合はIRQ1、PS/2マウスの場合はIRQ12）がありました。

これは、キーが押されたとき、CPUへのほぼ直接の回線があることを意味しました（PICを介して;それでも、1つだけジャンプします）。これにより、特にIRQ1があったため、キーボードイベントをハードウェアで非常に高速に処理できました。 （もちろん、これはすべて通常のキーボードの使用法に関するものであり、キーボードコントローラーからCPUに直接つながるリセットラインを無視します。）

一方、USBデバイスはすべて同じバスとUSBコントローラーのIRQ（通常、NIC、ビデオカードなどの他のデバイスと共有されるIRQステアリングデバイスの1つ）を共有します。そのため、USBキーボードの場合、イベントはキーボードコントローラーからUSBバスを経由してUSBホストコントローラーに移動し、そこからセカンダリPIC、マスターPIC、OSまたはBIOSのいずれかのドライバーに移動します。 、次にCPUに。また、USB経由で転送されるデータにエラーチェックデータが追加されています。

言い換えれば、ATまたはPS/2キーボードよりもUSBキーボードの方が多くのことが起こっています。データパスが長く、データが多いため、必要になる場合もあります。通過ソフトウェア。USB帯域幅は十分に大きいですが、同じポートに他のデバイスがあると、衝突と遅延が発生します（ハブを追加できますが、ハブ上のすべてのポートは、コントローラ）。したがって、さらに多くの待機が進行中です。

さらに、独自のものを持っている（IRQは、古いキーボードが必要なときにいつでもCPUの処理を中断できることを意味しました。USBでは、キーボードにはそのようなメカニズムがなく、一部のデータを送信し、USBコントローラーがCPUを中断するのを待つ/期待することしかできませんある時点で。

仮想キーボードは、間違いなくソフトウェアを通過するため、さらに悪化します。もちろん、ハードウェアラインと競合することはできません。

ATまたはPS/2キーボードとUSBキーボードの違いを簡単に視覚化したものを次に示します。

enter image description here

17
Synetech

短い答え

両方のキーボードは、ユーザーレベルのコードに対して完全に同等に機能します。デバイスドライバを作成する場合、わずかな違い（nano-からmicro-秒（最近のPCでは））がある可能性があります。システムがハングした場合、両方のキーボードで問題が解決しません。ハードリブートに行きます。

ロングアンサーTL; DR;

割り込みとは何ですか？

ハードウェア（またはカーネルなどのOS内部ソフトウェアの重要な部分）がプロセッササービスを必要とする場合、メッセージまたは 割り込み を起動し、プロセッサに実行中の処理を延期してこの要求を処理するように要求します。 。

使い方？

ハードウェアが割り込みを生成すると（キーを押すなど）、この要求は割り込みコントローラーに送られます。次に、コントローラーはマシンコードの1行でCPUにすぐに割り込みます（CPUはこの最後の行を実行します）。プロセッサがこの要求を処理する準備ができると、割り込みコントローラに 割り込み要求 （IRQ）と処理ルーチンを要求します。 割り込みコントローラー 内部データ構造があります 割り込みディスパッチテーブル 特定のIRQに対してCPUによって実行されることになっているルーチンへのポインターが含まれています。

すべての異なる割り込みは、明確に定義された制限に対応します 割り込み要求レベル （IRQL）。たとえば、x86システムでは32個のIRQLがあり、x64とIA64では実際には16個のIRQLがあります。明らかに、IRQLよりも多くのハードウェアデバイスとソフトウェアサービスがあるため、一部のシステムオブジェクトはすべてIRQLを共有します。

X64のIRQLテーブル

 IRQL |説明
 -------------------------------------------- 
 15 |ハイ/プロファイル
 14 |プロセッサ間割り込み/電源
 13 |時計
 12 |同期
 11 |デバイスN 
 .. | ... 
 3 |デバイス1 
 2 |ディスパッチ/DPC
1| APC 
 0 |パッシブ/低

IRQLが高い（数値が大きい）ほど、優先度が高くなります。システムのすべてのコンポーネントは、プロセッサの現在のIRQLを可能な限り低いレベル-0に維持しようとします。より高いレベルの割り込みが発生すると、プロセッサの現在のIRQLレベルが上がり、より低いレベルの割り込みは処理されます。より高いレベルのすべての割り込みが解決されます。 IRQスケジューラーがプロセッサー実行のために同じレベルの複数のIRQをキューに入れることができる場合、IRQはバッチ処理できます。

ポイントは？

これはすべて、エンドユーザーをハードウェアの複雑さから分離し、多くの種類のハードウェア/ソフトウェアで動作できるユニバーサルアーキテクチャを作成するように設計されています。

  1. ユーザーレベルのコード（つまり、カーネルレベルではない）は、プロセッサがパッシブ/ロー（0）IRQLにある場合にのみ実行されます。ポイントは、次のことができます。すべてのIRQLが処理された後でのみ、アプリケーションでキーが押されたイベントを処理します。したがって、キーボードの場合、ハードウェア割り込みにどのIRQLが割り当てられているかは関係ありません。

  2. IRQLはOSの抽象化であり、stoneには設定されていません。対応するIRQとIRQLは（たとえば）Windowsレジストリに保存され、熱心なユーザーなら誰でも手動で変更できます。

結論

質問からの引用

USBキーボードは、少数のIRQチャネルにしかアクセスできないUSB汎用ドライバーとアーキテクチャに依存しているため、別の（PS2などの）コントローラーほど優先度の高いIRQへのキーボードアクセスを提供することはできません。

おそらく、作者は少ないIRQチャネルではなく低いIRQLを意味していました。とにかく、最近のPCではユーザーに表示されないため、実際には問題ではありません。考えられる違いは、nano-からmicro-秒レベルであり、カーネルレベルでのみ発生します。どちらの場合も、ユーザーレベルのコードはOSカーネルによってブロックされます。

これは（それが本当の場合）、USBキーボードが別のポートタイプに接続されたキーボードよりも応答性が低いことを意味しますか？

OSの設計方法のため、これは真実ではありません。 OSが何かでビジーで「遅い」場合、両方のキーボードは同じように動作します。

たとえば、別の中優先度割り込みルーチンでスタックしている障害のあるシステムで、中優先度IRQにマップされたUSBキーボードを取り上げます。

この場合、システムはBSODになり、IRQ処理ルーチンは特定の標準に合わせて設計する必要があります（高速、同期、非ブロッキングなど）。これとカーネルからの逸脱はBSODになります。

優先度が比較的等しいため、キーボードイベントは無視され、Ctrl-Alt-delやその他の緊急キーストロークを送信することはできません。

システムがハングした場合、問題が発生する可能性のあることがたくさんありますが、ほとんどの場合、キーストロークIRQLはドライバーレベルで処理されます。問題は、OSが他のことをするのに忙しいため、そのような通知をサブスクライブしたアプリケーションに配信されないことです。

14
oleksii