カーネルメモリーアロケータ

Solaris カーネルメモリーアロケータは、カーネル内の各エンティティに使用するメモリーの断片を配分します。アロケータは、そのクライアントが使用するさまざまなサイズのキャッシュを作成します。一方、クライアントは、特定サイズの構造体の割り当てのためなど、クライアントが使用するキャッシュの作成をアロケータに要求できます。アロケータが管理する各キャッシュに関する統計は、kstat -c kmem_cache コマンドで表示できます。特殊化されたキャッシュを参照するには、crash(1M) コマンドで kmastat 演算子を使用します。

メモリーが壊されたために、システムがパニックになることがまれにあります。カーネルメモリーアロケータは、アロケータについての情報を収集するとともに、バッファに対してさまざまな整合性チェックを行うデバッグインタフェースをサポートします。整合性チェックは、エラーが実際に起こった場所の近くでエラーを検出するのに役立ちます。収集された情報は、サポート担当者がパニックの原因を特定する上で追加のデータを提供してくれます。

フラグを使用すると、システム操作で余分なオーバーヘッドと余分なメモリーの使用が発生します。したがって、フラグの使用は、メモリーの損傷が疑われるときだけに限るべきです。

kmem_flags

説明

Solaris カーネルメモリーアロケータには、Solaris 環境の内部的開発サイクル中に頻繁に使用されたさまざまなデバッグやテストのオプションがあります。Solaris 2.5 より前のリリースでは、これらのオプションを、リリースされた Solaris バージョンで使用することはできませんでした。しかし、Solaris 2.5リリース からは、これらのオプションのサブセットが利用でき、kmem_flags 変数で制御されます。kmem_flags 変数を設定するには、kadb をブートし、その後カーネルを開始する前にこの変数を設定しました。カーネルメモリーアロケータのインスタンス化と /etc/system の解析のタイミングの問題のため、これらのフラグは Solaris 8 より前のリリースでは /etc/system ファイルに設定できませんでした。

以下に、サポートされる 5 つのフラグの設定について説明します。

表 2-1 kmem_flags の設定値

フラグ	設定	説明
AUDIT	0x1	アロケータは、自身の活動の最近の履歴が入ったログを維持します。ログされる項目の数は、CONTENTS も設定されているかどうかによって異なります。ログのサイズは固定であるため、空間が足りなくなると、古いレコードから順に再使用されます。
TEST	0x2	アロケータは解放されたメモリーにパターンを書き込み、そのバッファを次に割り当てるときに、そのパターンが変更されていないことをチェックします。バッファの一部が変更されている場合は、そのバッファを前に割り当て、開放したエンティティがそのメモリーを使用した可能性が強いことがわかります。上書きが検知されると、システムがパニックになります。
REDZONE	0x4	アロケータは要求されたバッファの終りに余分のメモリーを割り当て、そのメモリーに特殊なパターンを挿入します。そして、バッファが解放されたら、パターンをチェックして、データがバッファの終りより後ろに書き込まれていないか調べます。上書きが検知されると、カーネルがパニックになります。
CONTENTS	0x8	アロケータは、バッファが解放されると、バッファの内容を 256 バイトまでログします。同時に AUDIT も設定する必要があります。 これらのフラグの数値は、論理和をとる (OR) ことができ、Solaris 8 リリースでは /etc/system ファイルで設定し、それより前のリリースでは kadb をブートして、カーネルを開始する前にこれらのフラグを設定します。
LITE	0x100	バッファの割り当てや解放で最小限の妥当性検査を行います。このフラグが有効になっていると、アロケータは、レッドゾーンが書き込まれていないことや、解放されたバッファが再び解放されていないこと、解放されるバッファのサイズが割り当てられたものと同じであることをチェックします。このフラグは、Solaris 7 3/99 リリースから使用できるようになりました。このフラグは他のフラグと併用しないでください。

データ型

符号付き整数

デフォルト

0 (無効)

範囲

0 (無効)、1 〜 15、256 (0x100)

動的か

はい。実行時の変更は、新しいカーネルメモリーキャッシュだけに有効です。システムの初期設定後に新しいキャッシュを作成することはまれです。

検査

なし

どのような場合に変更するか

メモリーの損傷が疑われる場合

コミットレベル

変更の可能性あり