次の声明を読みました。
x86 アーキテクチャには、ハードウェア コンテキストを格納するために、タスク状態セグメント (TSS) と呼ばれる特定のセグメント タイプが含まれています。Linux はハードウェア コンテキスト スイッチを使用しませんが、システム内の個別の CPU ごとに TSS を設定する必要があります。
不思議なんだけど：
最後に、いつものように、あなたの忍耐と返信に感謝します。
- - - - - -追加した - - - - - - -
http://wiki.osdev.org/Context_Switchingに説明があります。
私と同じくらい混乱している人は、それを見ることができました。8^)
x86 TSS は、ハードウェア マルチタスキングでは非常に遅く、ソフトウェア タスク スイッチングと比較した場合、ほとんどメリットがありません。（実際、手動で行うとTSSを何度も打ち負かすと思います）
TSS は面倒で面倒なことでも知られており、x86-64 への移植性もありません。Linux は複数のアーキテクチャで作業することを目的としているため、マシンに依存しない方法で記述できるため、おそらくソフトウェア タスク スイッチングを使用することを選択しました。また、ソフトウェア タスクの切り替えは、実行できることに対してより多くの機能を提供し、一般的に TSS よりもセットアップが簡単です。
Windows 3.1 は TSS を使用していたと思いますが、少なくとも NT >5 カーネルは使用していません。TSS を使用する Unix ライクな OS を私は知りません。
TSSは必須であることに注意してください。ただし、OS が行うことは、(プロセッサごとに) 単一の TSS エントリを作成することであり、タスクを切り替える必要があるたびに、この単一の TSS を変更するだけです。また、ソフトウェア タスク スイッチングによって TSS で使用される唯一のフィールドはESP0とSS0です。これは、割り込み用のリング 3 コードからリング 0 に到達するために使用されます。TSS がなければ、既知のリング 0 スタックは存在せず、もちろん GPF につながり、最終的にはトリプル フォールトになります。
Linux は、iirc 1.3 より前の時間枠で、HW ベースのスイッチングを使用していました。sw ベースのコンテキスト切り替えはより高速で、より柔軟であることが判明したと思います。
別の理由は、アーキテクチャ固有のコードを最小限に抑えていた可能性があります。非 x86 アーキテクチャへの Linux の最初の移植は Alpha でした。Alpha には TSS がなかったため、すべてのアーキテクチャが SW スイッチングを使用していれば、より多くのコードを共有できました。(ただの推測です。) 残念ながら、カーネル 1.2 から 1.3 までのカーネルの変更ログは十分に保存されていないため、これ以上特定することはできません。
Linuxはセグメント化されたメモリモデルを使用しないため、このセグメンテーション固有の機能は使用されません。
x86 CPUは、コンテキストスイッチングに対してさまざまな種類のハードウェアをサポートしているため、ハードウェアとソフトウェアの違いはありませんが、OSが利用可能なさまざまなハードウェア機能をどのように使用するかが異なります。それらすべてを使用する必要はありません。
Linuxは非常に効率に重点を置いているため、誰かが可能なすべてのオプションをプロファイリングし、現在使用されているオプションが利用可能な最善の妥協案であることに賭けることができます。