C文字列ライブラリを直接実装しようとすると、glibcとLinuxカーネルが特定の機能を異なる方法で実装することがわかりました。例えば、glibc メモリロガーそしてglibc 文字列機能を高速化するには、いくつかのトリックを使用してください。kernelmemchrそしてカーネルstrchrいいえ。 Linuxカーネル機能がglibcのように最適化されていないのはなぜですか？
答え1
カーネルは、アーキテクチャ固有のディレクトリにこれらの機能のいくつかの最適化されたバージョンを提供します。x86の実装memchr（望むよりすべてのmemchr定義とすべてのstrchr定義）。見つかったバージョンは代替一般バージョンです。と#ifndef __HAVE_ARCH_MEMCHRの保護チェックを見つけてそれを見つけることができます。memchr#ifndef __HAVE_ARCH_STRCHRstrchr
Cライブラリの最適化されたバージョンはより複雑なコードで動作する傾向があるため、上記はカーネルがスピードを上げようとしない理由を説明していません。カーネルがこれらの機能の1つのより最適化されたバージョンから恩恵を受ける可能性があるシナリオを見つけることができれば、パッチが歓迎されると思います（適切なサポート証拠があり、最適化された機能がまだ理解できる限り - 参照）。この古い議論はmemcpy）。しかし、私は通常、カーネルがこれらの関数を使用するのにそれほど価値がないと思います。たとえば、memcpy関連関数はカーネルの小さなバッファで使用される傾向があります。そして、キャッシュに合ったりインライン化したりできる短い関数による速度向上を過小評価しないでください。
さらに、次のように私は存在しません 私は存在しません、MMX と SSE はカーネルでは簡単に使用できません。、メモリ検索またはコピー機能の多くの最適化されたバージョンがこれに依存します。
ほとんどの場合、使用されるバージョンは次のとおりです。コンパイラの組み込みバージョンそれにもかかわらず、それらはCライブラリよりもはるかに最適化されています（たとえば、memcpyレジスタのロードと保存、または定数ストアにしばしば変換されます）。
答え2
2006年にSolarisでmkisofs。
ISOフォーマットソフトウェアは、ISO-9660ディレクトリエントリの途中にRock Ridgeファイル名を含めません（たとえば、mkisofsISO-9660ディレクトリエントリの末尾には含まれています）。
場合によっては、Solarisカーネルの（当時過度に最適化された）文字列ルーチンが1を超えることがあり、Rock Ridgeファイル名が2kセクタの終わりで終了し、4kの場合ENDになることがありました。カーネルメモリページでは、このような過剰アクセスにより、不正なメモリアクセスが原因でカーネルパニックが発生する可能性があります。
将来、この種のカーネルパニックを防ぐために、アクセスコードを非常に保守的に書き直す必要があります。
見てわかるように、カーネルの安全なコードを書くのは時々はるかに難しく、これらのコードはカーネルパニックを避けるために遅くなるかもしれません。
注：MMUページの終わりに到達することが可能な場合は、リンカーにセグメントの後に数バイトを追加させることで、ユーザー空間プログラムのCPUで予測不能なプリパッチを処理できます。これは、マップされた領域に依存するカーネルでは機能しません。