Linuxカーネルバージョン3.9.4を構成しています。 RCUについて質問されています(以下を参照)。具体的には、これらはそれぞれ何であり、これらのいくつかを有効または無効にすることの利点と欠点は何ですか?
Consider userspace as in RCU extended quiescent state (RCU_USER_QS) [N/y/?]
Tree-based hierarchical RCU fanout value (RCU_FANOUT) [64]
Disable tree-based hierarchical RCU auto-balancing (RCU_FANOUT_EXACT) [N/y/?]
Accelerate last non-dyntick-idle CPU's grace periods (RCU_FAST_NO_HZ) [Y/n/?]
Offload RCU callback processing from boot-selected CPUs (RCU_NOCB_CPU) [N/y/?]
LTTng Project サイトには、これらのオプションに関するいくつかの詳細があります。 RCUは(read-copy-update)です。これらはカーネル内のデータ構造であり、マルチコアCPUのコア間で同じデータを複製でき、コピー間でデータの同期が保たれることを保証します。
抜粋
liburcuはLGPLv2.1ユーザー空間RCU(読み取り-コピー-更新)ライブラリです。このデータ同期ライブラリは、コアの数に比例してスケーリングする読み取り側アクセスを提供します。これは、特定のデータ構造の複数のコピーが同時に存続できるようにし、データ構造のアクセスを監視して猶予期間を検出することにより、メモリの再利用が可能になることで実現します。
このオプションは、CPUがユーザースペースで実行されると、フックをカーネル/ユーザースペース境界に設定し、RCUを拡張静止状態にします。これは、CPUがユーザースペースで実行されると、グローバルRCUステートマシンから除外されるため、RCUのタイマーティックを維持しようとしないことを意味します。
ハッキングしてフルdynticksモードの開発を支援したい場合を除き、このオプションを有効にしないでください。また、不要なオーバーヘッドが追加されます。
よくわからない場合はN
このオプションは、RCUの階層実装のファンアウトを制御し、RCUが多数のCPUを搭載したマシンで効率的に動作できるようにします。この値は、少なくともNR_CPUSの4番目のルートでなければなりません。これにより、NR_CPUSが非常に大きくなる可能性があります。本番システムではRCU_FANOUTのデフォルト値を使用する必要がありますが、RCU実装自体のストレステストを行う場合、RCU_FANOUT値を小さくすると、小規模なシステムで大規模システムのコードパスをテストできます。
RCU自体をテストする場合は、特定の番号を選択します。不明な場合は、デフォルトを使用してください。
このオプションは、階層の不均衡に関係なく、指定された正確なRCU_FANOUT値の使用を強制します。これはRCU自体のテストに役立ち、NUMAの動作が強いシステムではいつか役立つかもしれません。
RCU_FANOUT_EXACTがない場合、コードは階層のバランスをとります。
不明な場合はNと言ってください。
このオプションは、RCUコールバックがキューイングされている場合でも、CPUがdynticks-idle状態に入るのを許可し、RCUがこれらのCPUを約4回に1回以上起動しないようにします(デフォルトでは、rcutree.rcu_idle_gp_delayパラメーターを使用してこれを調整できます)。エネルギー効率の向上。一方、このオプションはRCUの猶予期間を長くします。たとえば、synchronize_rcu()を遅くします。
エネルギー効率が非常に重要で、猶予期間の延長を気にしない場合は、Yと言ってください。
不明な場合はNと言ってください。
このオプションを使用して、攻撃的なHPCまたはリアルタイムワークロードのOSジッタを低減します。また、バッテリー駆動の非対称マルチプロセッサーのエネルギー効率の高いCPUへのRCUコールバック呼び出しのオフロードにも使用できます。
このオプションは、ブート時にrcu_nocbsパラメータで指定されたCPUのセットからのコールバック呼び出しをオフロードします。このような各CPUに対して、コールバックを呼び出すためのkthread( "rcuox/N")が作成されます。ここで、 "N"はオフロードされるCPUであり、 "x"はRCU-bhの "b"、 "p"です。 RCU-preemptの場合は「s」、RCU-schedの場合は「s」。このkthreadが指定されたCPUで実行されるのを妨げるものはありませんが、(1)各コールバック間でkthreadがプリエンプトされる可能性があり、(2)アフィニティまたはcgroupを使用して、必要なCPUのセットでkthreadを強制的に実行できます。
OSジッタの減少をデバッグしたい場合は、ここでYと言ってください。不明な場合は、ここでNと言ってください。
カーネルをコンパイルするときに特定のオプションが何をするのかわからない場合は、カーネルなしで生活できるのはおそらく間違いないでしょう。だから私はそれらの質問にノーと言います。
また、この種の作業を行う場合、通常、ディストリビューションで使用しているカーネルの構成ファイルを取得し、比較を行って、機能が不足していないかどうかを確認します。これは、すべての機能が何であるかを学ぶ上で、おそらく最良のリソースです。
たとえばFedoraには、参照できるサンプル構成が含まれています。詳細については、このページをご覧ください カスタムカーネルの構築 。