第10章 カーネル

10.1. リソース制御

10.1.1. RHEL 8 で、Control Group v2 がテクノロジーグループとして利用可能

Control Group v2 メカニズムは、統一された階層制御グループです。Control Group v2 は、プロセスを階層的に編成し、制御された設定可能な方法で、階層に従ってシステムリソースを分配します。

以前のバージョンとは異なり、control group v2 には階層が 1 つしかありません。このように階層が単純であるため、Linux カーネルでは次のことが可能になります。

  • 所有者の役割に基づいたプロセスの分類
  • 複数の階層でポリシーが競合する問題の解消

Control group v2 は、非常に多くのコントローラーに対応します。

  • CPU コントローラーにより、CPU サイクルの配分が調整されます。このコントローラーには以下が実装されています。

    • 通常のスケジューリングポリシーに対する重みおよび絶対帯域幅制限のモデル
    • 実時間スケジューリングポリシーに対する絶対帯域幅割り当てモデル
  • メモリーコントローラーは、メモリー配分を調整します。現在、次の種類のメモリー使用量が追跡されます。

    • ユーザー側のメモリー (ページキャッシュと匿名メモリー)
    • dentry、inode などのカーネルデータ構造
    • TCP ソケットバッファー
  • I/O コントローラーは、I/O リソースの配分を制限します。
  • Remote Direct Memory Access (RDMA) コントローラーは、一部のプロセスが使用できる、RDMA/IB に固有のリソースを制限します。このプロセスは、RDMA コントローラーによりグループ化されます。
  • プロセス番号コントローラーは、特定の制限後に、コントロールグループが、新しいタスクが fork() されない、または clone() されないようにできます。
  • Writeback コントローラーがメカニズムとして動作します。これは、I/O コントローラーとメモリーコントローラーとの間の矛盾が相殺されます。

上記の情報は、cgroups-v2 オンラインドキュメント に基づいています。ここでは、個別の control group v2 コントローラーに関する詳細を取得できます。

10.2. メモリーの管理

10.2.1. 64 ビット ARM に 52 ビット PA が利用可能

今回の更新で、64 ビット ARM アーキテクチャー用の 52 ビット物理アドレッシング (PA) に対応するようになりました。これにより、以前の 48 ビットの PA よりも大きな物理アドレス空間が提供されます。

10.2.2. 5 レベルのページテーブル x86_64

Red Hat Enterprise Linux 7 での既存のメモリーバスには、48/46 ビットの仮想または物理のメモリーアドレス機能があり、Linux カーネルが、4 つのレベルのページテーブルを実装して、物理アドレスへの仮想アドレスを管理します。物理バスのアドレス線は、物理メモリーの容量の上限を 64 TB に制限します。

この制限は、57/52 ビットの仮想および物理のメモリーアドレスにより、128 PiB の仮想アドレス空間 (64PB ユーザー/64PB カーネル) と、4 PB の物理メモリーの容量まで拡張されました。

拡張アドレス範囲を使用して、Red Hat Enterprise Linux 8 のメモリー管理では、5 レベルのページテーブルの実装への対応が追加され、拡張アドレス範囲を処理します。デフォルトでは、RHEL8 は、この機能に対応するシステムでも、5 レベルのページテーブルの対応を無効にします。これにより、仮想または物理のアドレス領域の拡張が必要ない場合に 5 レベルのページテーブルを使用すると、パフォーマンスが低下する可能性があります。起動引数は、この機能に対応するハードウェアを搭載するシステムがそれを使用できるようにします。

10.3. パフォーマンス分析と可観測性ツール

10.3.1. カーネルに bpftool が追加される

eBPF (extended Berkeley Packet Filtering) に基づくプログラムおよびマップの検査と簡単な操作を行う bpftool ユーティリティーが Linux カーネルに追加されました。bpftool はカーネルソースツリーの一部で、bpftool パッケージにより提供されます。これは、kernel パッケージのサブパッケージとして含まれています。

10.3.2. eBPF がテクノロジープレビューとして利用可能に

eBPF (extended Berkeley Packet Filtering) 機能は、テクノロジープレビューとしてネットワーキングおよびトレースの両方に利用できます。eBPF を使用すると、ユーザー空間はカスタムプログラムをさまざまなポイント (ソケット、トレースポイント、パケット受信) に接続してデータを受信して処理できるようにします。この機能には、新しいシステムコール bpf() が含まれます。これは、様々な種類のマップの作成と、様々な種類のプログラムの更新に対応します。bpf() は、root など、CAP_SYS_ADMIN が付与されているユーザーのみが利用できます。詳細は、man ページの bpf(2) を参照してください。

10.3.3. BCC がテクノロジープレビューとして利用可能に

BPF コンパイラーコレクション (BCC) は、Red Hat Enterprise Linux 8 でテクノロジープレビューとして利用できる、効率的なカーネルの追跡および操作プログラムを作成するユーザー空間ツールパッケージです。BCC は、eBPF (extended Berkeley Packet Filtering) を使用して、Linux オペレーティングシステムの I/O 解析、ネットワーキング、およびモニタリング用のツールを提供します。

10.4. ブートプロセス

10.4.1. RHEL 8 のカスタムカーネルをインストールしてシステムを起動する方法

Boot Loader Specification (BLS) は、スキームと、ファイルフォーマットを定義して、ドロップインディレクトリーの各起動オプションで、ブートローダー設定を管理します。それぞれのドロップイン設定ファイルを操作する必要はありません。Red Hat Enterprise Linux 8 では、すべてのアーキテクチャーで同じブートローダーを使用していないため、Red Hat Enterprise Linux 8 には特に関係があります。

  • Open Firmware を使用する x86_64aarch64、および ppc64leGRUB2 を使用する
  • Open Power Abstraction Layer (OPAL) を使用する ppc64lePetitboot を使用する
  • s390xzipl を使用する

各ブートローダーには、新しいカーネルがインストールまたは削除された場合に修正が必要な設定ファイルおよびフォーマットが異なります。以前のバージョンの Red Hat Enterprise Linux では、grubby ユーティリティーが、この動作を可能にするコンポーネントでした。ただし、Red Hat Enterprise Linux 8 の場合、ブートローダーの設定は、BLS ファイル形式の実装により標準化されました。ここでは、grubby は、BLS 操作のシンラッパーとして動作します。

10.4.2. RHEL 8 における初期 kdump サポート

以前は、起動プロセスの初期段階で発生したカーネルクラッシュを登録するために kdump サービスの起動に時間がかかりすぎていました。このため、トラブルシューティングの可能性とクラッシュ情報が失われていました。

この問題に対処するために、RHEL 8 では、early kdump サポートが導入されました。このメカニズムの詳細は、/usr/share/doc/kexec-tools/early-kdump-howto.txt ファイルを参照してください。「What is early kdump support and how do I configure it?」も参照してください。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。