初心者向け：Linuxシステムの起動時間制限の最適化

（1）まずLinuxの起動プロセスの追跡と分析で、詳細な起動時間レポートが生成されます。

もっと簡単で実行可能な方法は、PrintkTime関数を使ってブートプロセスのすべてのカーネル情報にタイムスタンプを追加することです。これは、要約分析に便利です。 PrintkTimeはもともとCELFによって提供されたカーネルパッチであり、Kernel 2.6.11のそれ以降のバージョンで標準的なカーネルに正式に組み込まれました。そのため、新しいバージョンのカーネルでこの機能を直接有効にすることができます。何らかの理由でLinuxカーネルをバージョン2.6.11にアップデートできない場合は、CELFが提供する方法を参照して、提供されているパッチを修正または直接ダウンロードできます。http://tree.celinuxforum.org/CelfPubWiki/PrintkTimes

PrintkTime関数を有効にする方法はとても簡単です。カーネルの起動パラメータに "time"を追加するだけです。もちろん、ブートごとにカーネル情報のタイムスタンプを強制するようにカーネルをコンパイルするときに、「カーネルハッキング」で「プリントタイミング情報を表示する」を直接指定することもできます。この方法にはもう1つの利点があります。起動パラメータを解析する前に、カーネルに関するすべての情報を取得できるということです。したがって、私は後者の方法を選びました。

上記の設定が完了したら、Linuxを再起動し、次のコマンドでカーネルのブート情報をファイルに出力します。

dmesg -s 131072> ktime

次に、スクリプト「show_delta」（Linuxソースコードのscriptsフォルダにあります）を使用して、上記の出力ファイルを時間増分表示形式に変換します。

/usr /src /Linux-x.xx.xx /scripts /show_delta ktime> dtime

このようにして、Linuxの起動時間の消費に関する詳細なレポートを得ることができます。

（2）次に、このレポートを使用して、起動時に比較的時間のかかるプロセスを見つけます。

レポートの時間増分とカーネル情報の間に必要な対応がないことは明らかでなければなりませんリアルタイム消費はカーネルソースから分析されなければなりません。

これはプログラミングに少し慣れている友人には難しくありません。時間の増分はprintkを2回呼び出す間の時間差にすぎないからです。一般的に言って、カーネル起動プロセスの間に、ハッシュインデックスやプローブハードウェアデバイスの作成などの時間のかかる作業を完了した後、結果はprintkによってプリントアウトされます。時間がかかりますが、場合によっては、カーネルはprintk出力情報を呼び出した後に対応するプロセスを開始し、レポート内のカーネル情報の対応するプロセスの時間消費は次の行の時間増分に対応します。カーネル情報の出力間の不確定な期間では、そのような時間増分はカーネル情報によって全く反映されないかもしれない。

したがって、実際の時間消費を正確に判断するためには、カーネルのソースコードを分析する必要があります。上記の3番目のケースのように、必要に応じて、実際の時間消費プロセスをさらに決定するために、ソースコードにprintkプリントを挿入する必要があります。

前回のカット後のLinuxカーネルの起動解析は次のとおりです。

カーネル起動の合計時間：6.188秒

キーの消費時間部分：

1）0.652秒 - タイマー、IRQ、キャッシュ、Memページなどのコア部分の初期化

2）0.611秒 - コアとRTCクロックの同期

3 0.328秒 - キャリブレーション遅延の計算（4 CPUコアの総消費量）

4）0.144秒 - APICクロックのキャリブレーション

5）0.312秒 - マイグレーションコストのキャリブレーション

6）3.520s - Intel E1000 NICの初期化

以下では、各部を1つずつ分析して解決します。

（3）次に、特定の部分最適化を実行します。 CELFは、家電製品に使用される組み込みLinux向けの一連の起動最適化ソリューションを提案していますが、さまざまなアプリケーションを対象としているため、それらの経験から部分的にしか学ぶことができません。具体的な分析を行い、問題を試してください。

カーネルの重要部分（Timer、IRQ、Cache、Mem Pagesなど）の初期化は、現在のところ信頼性が高く実行可能な最適化ソリューションではないため、考慮されていません。

上記の分析結果のうちの2つと3つに対して、CELFは特別な最適化スキームを持っています：“ RTCNoSync”と“ PresetLPJ”。

前者は、起動時にRTCクロック同期をマスクするか、起動後にこのプロセスをオンにすることで（アプリケーションのクロック精度に対するニーズに応じて）実装が簡単です。カーネルにパッチを当てる必要があります。 CELFの現在の仕事は単にプロセスを削除することであり、言及されたRTCクロック同期の「スヌーズ」処理を実装していないようです。このため、この最適化はしばらくの間私のソリューションには導入されていません（結局のところ、それがもたらした時間ドリフトは "第2"レベルに達しています）。

後者は、スタートアップパラメータにLPJ値を指定することで実際の計算プロセスをスキップします。これは、同じハードウェア条件下でLPJ値が変化しないことに基づいています。したがって、通常の起動後にカーネル情報に "Calibrating Delay"値を記録した後、次の形式で起動パラメータにLPJ値を強制することができます。

lpj = 9600700

上記の分析結果の4と5はSMPの初期化の一部であるため、CELFの研究の範囲には含まれず（おそらく将来的にはマルチコアMP4があるのでしょうか... ...）、そしてそれは自立のみです。 SMPの初期化コードを調査した後、 "Migration Cost"でも "Calibrating Delay"のように事前設定された方法でキャリブレーション時間をスキップできることがわかりました。この方法は似ており、最後にカーネルの起動パラメータに追加されました。それはオープンソースでもありますが、IntelのNICドライバの初期化の最適化はより面倒です。しかし、ハードウェアドライバを読むことは、一般的なCコードを読むことよりも優れているわけではありません。信頼性を考慮して、両方の試みが失敗した後、私はついにこの道をあきらめた。別の見方をすると、 "ParallelRCScripts"スキームのCELFの "パラレル初期化"の考え方から学び、NICドライバをモジュールに独立してコンパイルし、他のモジュールやアプリケーションと同期して初期化スクリプトに読み込むことができます。時間の影響実際のハードウェア環境では、アプリケーションの初期化でもネットワークが使用される可能性があることを考慮すると、プロビジョニングにはeth0のみが使用されるため、最初のネットワークポート初期化の0.3秒の時間をカウントする必要があります。

私のプログラムで遭遇した上記の最適化ポイントに加えて、CELFはあなたが興味を持つかもしれない具体的な最適化も提案します。例えば：

ShortIDEDelays - IDEの検出時間を短縮します（アプリケーションではハードディスクを使用しないので使用できません）

KernelXIP - カーネルをROMまたはフラッシュで直接実行します（互換性の要因を考慮し、使用しません）。

IDENoProbe - 接続されていないデバイスのIDEポートをスキップする

OptimizeRCScripts - initrdでlinuxrcスクリプトを最適化する（私はもっと簡潔なlinuxrcにBusyBoxを使用しました）

まだ想像されている段階にある他の最適化と同様に、興味がある友人はより多くの情報のためにCELF開発者Wikiを訪問することができます。

（4）最適化結果

上記の特別な最適化、inittabおよびrcSスクリプトの冗長性削減の結果、Linuxカーネル全体の起動時間は最適化前の6.188からとなりました。 eth0の初期化が含まれていない場合は1.708秒で済み（eth0の初期化はシステムミドルウェアおよび一部のアプリケーションのロードと並行して行うことができます）、基本的に確立された目標を達成します。 Kexecと組み合わせると、ソフトウェア障害によるリセット時間を大幅に短縮でき、製品の信頼性が効果的に向上します。