LinuxがTSSを介してハードウェアコンテキストスイッチを使用しないのはなぜですか？
私は次の声明を読みました：
X86アーキテクチャには、ハードウェアコンテキストを格納するために、タスク状態セグメント（TSS）と呼ばれる特定のセグメントタイプが含まれています。 Linuxはハードウェアコンテキストスイッチを使用しませんが、それでもシステム内の個別のCPUごとにTSSを設定する必要があります。
不思議なんだけど：
- Linuxがコンテキストスイッチのハードウェアサポートを使用しないのはなぜですか？
- ハードウェアアプローチはソフトウェアアプローチよりもはるかに高速ではありませんか？
- ハードウェアコンテキストスイッチを利用するOSはありますか？ Windowsはそれを使用しますか？
最後に、いつものように、あなたの忍耐と返事に感謝します。
-----------追加--------------
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は、1.3より前のタイムフレームiircで、HWベースのスイッチングを使用していました。 swベースのコンテキスト切り替えはより高速で、より柔軟であることがわかったと思います。
もう1つの理由は、Arch固有のコードを最小化したことである可能性があります。 Linuxの非x86アーキテクチャへの最初の移植はAlphaでした。 AlphaにはTSSがなかったため、すべてのアーチでSWスイッチングを使用すると、より多くのコードを共有できました。 （推測です。）残念ながら、1.2〜1.3カーネル期間のカーネル変更ログは十分に保存されていないため、これ以上具体的にすることはできません。
Linuxはセグメント化されたメモリモデルを使用しないため、このセグメンテーション固有の機能は使用されません。
x86 CPUは、コンテキストスイッチングに対してさまざまな種類のハードウェアをサポートしているため、ハードウェアとソフトウェアの違いはありませんが、OSが利用可能なさまざまなハードウェア機能をどのように使用するかが異なります。それらすべてを使用する必要はありません。
Linuxは非常に効率に重点を置いているため、誰かが可能なすべてのオプションをプロファイリングし、現在使用されているオプションが利用可能な最善の妥協案であることに賭けることができます。