HA Clustering (SAF based)
1: Prepare modified load module as shared object using standard compiler
3.5 ライブパッチの適応性評価
表3.2.評価環境
CPU Pentium Xeon 2.8GHz ×2 (HT により4SMT)
Memory 2GByte
HDD 160GByte SATA-1
カーネル 2.6.9にライブパッチ方式を実装
0 50 100 150 200
100 500
1000150020002500 3000 3500 4000 4500 5000 5500 60006500 7000
Number of functions to live patch at once.
Process live-patching for single threaded process using ptrace() mechanism.
Process live-patching for multi threaded process using
mmap3()/accesspvm() mechanism.
200 threads 1 thread 50 threads 100 threads 150 threads Stopping time
(milli seconds)
図3.12.プロセスライブパッチ実施時の修正対象プロセスの停止時間
数が1の場合には，およそ5400個の関数修正を100ms以内に実施することが可能である．
3.1に示したとおり要求される処理時間は，PSTN及びISDNに代表される電話サービスで は16ms，IPネットワークを使用した電話サービスでは100ms以下である．このタイムアウ ト値以内にプロセスライブパッチによるプロセス停止時間が収まる限り，複数ホップを経由す る場合に各システム内で遅延が生じても，ネットワーク全体にわたって要求されるサービス品 質を保つことができる．
この結果から，いずれの電話サービスでもptrace()を用いた実装及びプロセスライブパッ チの両方において，スレッド数及び一度に修正する関数数に一定の制約を設けることで，サー ビスのタイムアウト値以内にオンライン修正可能であることが分かる．更にプロセスライブ パッチでは修正する関数数及びスレッド数に対する制約がptrace()を用いた実装よりも緩い．
電話サービスのソフトウェアは場合によって数多くのスレッドを有し，一度に非常に数多く の関数及びデータを修正する．このため多くのスレッドと関数の修正を行えることは重要であ る．プロセスライブパッチはptrace()を用いた実装よりも，修正する関数数及びスレッド数 に対する制約が緩く，実サービスに適している．
また本計測に使用した修正対象プロセスは擬似呼処理プロセスであり，実環境の呼処理プロ セスとは実装が異なるため負荷状況によっては結果が異なる可能性もある．このためプロセス ライブパッチを開発中のISDNの交換システムに適用し，呼処理プロセスの不具合にオンライ ン修正を実施した場合でも，シミュレーション呼の実時間性が阻害されないことを確認した．
ライブパッチ時のプロセス停止時間の考察
図3.13，図3.14，図3.15にプロセスライブパッチの停止時間の内訳を示し，それぞれ考察 する．
図3.13は，CPUスケジューラ上のターゲットプロセスのいずれかのスレッドの実行状態を 停止してから，すべてのスレッドの実行状態を停止しjump書込み状態になるまでに要した処 理時間を示している．スレッド数が増加するにつれて，実行状態の変更に時間が増加している のは，スレッドごとに実行状態を変更するためである．
また修正する関数数が増加すると停止するまでの時間が上昇している．これは各タスクの実 行アドレスと修正アドレスの競合判定数が増加することと，競合時のリトライ処理のためであ る．修正関数とスレッド数が増加することでチェック回数及び競合するケースが増え，リトラ イ回数が増加し停止状態になるまでの時間が増加することを示している．
図3.14は，jump命令を上書きする処理時間，すなわち数ワードから構成されるjump命令 のバイト列をメモリに書き込むライト命令の処理時間を示しており，スレッド数による上書き 時間の差分がないことが分かる．またこのjump命令上書きに要する時間は，最大で全体の停 止時間の80%超を占めていることが分かる．
図3.15は，スケジューラ上のターゲットプロセスの実行状態を復旧するまでに要した処理 時間を示しており，停止と同様にスレッド数が増加するにつれて実行状態の変更の処理時間が 増加していることが分かる．この処理時間は3.4.1で示したSIGCONTの送信に要した時間
であり，SIGCONTの送信処理の過程でターゲットプロセスの実行状態が実行可能に変更さ
0 5 10 15 20 25 30 35 40
100
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Number of functions to live patch at once.
Stopping time (milli seconds)
200 threads
1 thread 50 threads 100 threads 150 threads
図3.13.プロセスライブパッチにてスケジューラ上のプロセス実行状態を停止するまでの時間
0 20 40 60 80 100 120 140 160 180 200
100 500
1000 1500
2000 2500
3000 3500
4000 4500
5000 5500
6000 6500
7000 7500
8000 8500
9000 9500
10000
Number of functions to live patch at once.
Stopping time (milli seconds)
200 threads
1 thread 100 threads 50 threads 150 threads
図3.14.プロセスライブパッチでのjump命令上書き時間
0.5 0 1 1.5 2 2.5 3 3.5 4 4.5 5
100
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Number of functions to live patch at once.
Stopping time (milli seconds)
200 threads
1 thread 50 threads 100 threads
150 threads
図3.15.プロセスライブパッチにてスケジューラ上のプロセス実行状態を復旧するまでの時間
れる．実行状態の復旧の方が停止に比べて遥かに高速である理由は停止時に生じた競合判定処 理及びアドレスの競合が復旧時には発生しないためである．
3.5.2 カーネルライブパッチの評価と考察
カーネルライブパッチを実施した際のカーネルの停止時間について実験を行い計測・評価し た．結果を図3.16に示す．図3.16のX軸は一度にいくつの関数を修正するか，すなわち同時 に上書きするjump命令の数を示し，Y軸はカーネルの停止時間を対数で示す．
グラフはカーネルの修正を行う際に，kexec[48]を用いた結果と，カーネルライブパッチを 用いた結果を示す．kexecは3.2.1に示したとおりハードウェアの初期化を行わずに，修正さ れたカーネルの再ロードを高速に行う技術である．kexecは以下の手順で再ロードを行う．
(1) 修正カーネルをカーネルメモリ空間にロード
(2) ロードされた修正カーネルの処理開始アドレスにCPUの実行アドレスを変更 (3) 通常のカーネル初期化処理を実施し，initscriptを実施
Kexecでの(1)の処理では，旧カーネルの動作が継続されており，(2)の処理から，修正カー
ネルの処理が開始される．
kexecでの時間を測定した範囲は(2)-(3)の修正カーネルの処理が開始されてから修正カー
ネルの起動完了までのカーネルの停止区間の時間測定を行った．この結果，実験に用いたハー ドウェアでは，約85秒を再ロードに要しており，kexecでは電話サービスへの適用が困難で ある．
一方，カーネルライブパッチでは，およそ10000関数の修正を行っても停止時間は1ミリ秒 程度であり，kexecに比べて極めて高速である．この結果から，いずれの電話サービスに対し てもリアルタイム性を阻害せずにオンライン修正可能である．
またこの結果はプロセスライブパッチに比べても高速である．これはjump命令を上書きす るという処理は同一であるが．jump命令を上書きするアドレスが，修正対象プロセス内のア ドレスか，カーネル内のアドレスかという点が異なる．
具体的には修正対象プロセス内のメモリ空間を上書きする場合には，各プロセスのメモリ マッピング管理情報を更新する必要がある．一方，カーネル内のアドレスであれば，プロセス 単位でのメモリ管理情報の操作は必要ない．この点が処理時間の差の要因である．