From sugita ＠ sdl.hitachi.co.jp Mon Jul 1 21:36:44 2002 From: sugita ＠ sdl.hitachi.co.jp (Yumiko Sugita) Date: Mon, 01 Jul 2002 21:36:44 +0900 Subject: [Lkst-develop] sourceforge.jpのLKSTページにＨＰとv1.2 のリリース情報を登録 Message-ID: <5.0.2.6.2.20020701212625.04b239f8@sdl99c> 各位 　sourceforge.jpのLKSTページにホームページとv1.2のリリース情報を 登録しました。ページにアクセスできるか、ダウンロードできるか、ダウン ロードしたものが使えるか、など、試してみて下さい。 　なお、リリース情報はsourceforge.netと日時をあわせましたが、各ファ イルの登録日時は変更できず、今日の日時になっています。次回からは この時間差をなるべくなくしたいと思います。 　アクセスして何かご意見があればメーリングリストに下さい。 杉田＠LKST管理者Ｇｒ 　 From hiramatu ＠ sdl.hitachi.co.jp Tue Jul 2 15:46:21 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Tue, 02 Jul 2002 15:46:21 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 Message-ID: <3D214C3D.7060402@sdl.hitachi.co.jp> 日立の平松です。 lkst-1.2リリース直後ですが、現状新たに見つかった問題点と改善策 (修正中のものも含まれます)を明らかにしておきたいと思います。 ＃すこし長めになってしまいました。 (1)lkst_evhandler_register が 与えたIDのイベントハンドラを 上書き登録してしまう。このため、デフォルトのイベントハンドラ が登録されているIDに上書きしてしまうことができる。 改善策）lkst_evhandler_registerの仕様変更、lkst_evhandler_unregister 　　　　lkst_evhandler_get_idの2つのAPIの追加を行う。 　　　　registerに関しては、・システム予約IDへの変更不可、・IDの自動割当 　　　　・名前の重複禁止、の3点を中心に行います。 　　　　また、これまでNULLを登録することでevhandlerを削除してきましたが 　　　　専用のunregister関数を使うように変更します。 　　　　また、ハンドラに付けた名前からIDを引いてこれるようにget_idを 　　　　追加します。 　　　　この変更についてはこちらで修正済ですが、APIの変更に関して 　　　　何か問題等ありますでしょうか。 (2)バッファオーバーライト判定にバグの可能性。 (3)バッファ解放時に(ロックを取っていないので)アクセスバイオレーションを 　起こす可能性がある。 改善案）LKSTでは、CPU毎に書き込みバッファを持っているので、イベント取得 　　　　時にロックを極力省けるのですが、バッファリードやバッファの操作に 　　　　関しては担当していないCPUからの操作が入ってしまうことになり、上 　　　　記のような問題が発生します。そこで、これらのバッファ操作に関しては、 　　　　操作を行うプロセスを対象バッファを持つCPU上にmigrateして実行し、 　　　　ロックをとらなくてもすむようにしたいと考えています。 　　　　具体的には以下のように考えています。 (2) ・リードプロセス(ほとんどの場合lkstlogd)は、set_rmodによって対象CPUに migrateし 　リードコマンドを発行する。 ・読み出しと書き込みが同一CPUのカーネルタスク上で行われるため、オーバー リード・ 　オーバーライト判定をしなくてもよい。 (3) ・ カレントバッファでないか調べ、defunctフラグ(atomic)を立て（これは解放 プロセ ス中のバッファに、シフトインしないようにするためである）、再びカレント バッファ でないか調べる。2度目の確認で失敗したらdefunctフラグを倒してエラーで戻る。 （このプロセスは、バッファの解放、リストやリングからはずすときにも使われる） ・その後 バッファ解放プロセスは、cpus_allowedフラグを使ってバッファを使 うCPUへ スケジュールされるのを待ち、解放する。 ・シフトプロセスはdefunctフラグがたっていなければシフトする。 (4)デーモンにSIGTERMを送ったときにバッファを二度読んでしまう。 改善策）オーバーリードの判定とsignalの判定がうまく働かないために生じる現 象ですが、 　　　　上記のようにオーバーリード判定が不要になれば自然に治るのではないかと 　　　　思われます。 　　　　また、もう一つの案として、SIGTERMを送ると同時にバッファシフトさ せると 　　　　いう方法が考えられています。 以上です。 ご意見いただけるとありがたいです。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 From hiramatu ＠ sdl.hitachi.co.jp Wed Jul 3 14:29:29 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Wed, 03 Jul 2002 14:29:29 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 References: <3D214C3D.7060402@sdl.hitachi.co.jp> Message-ID: <3D228BB9.50400@sdl.hitachi.co.jp> 日立の平松です。 Masami HIRAMATSU wrote: > (1)lkst_evhandler_register が 与えたIDのイベントハンドラを > 上書き登録してしまう。このため、デフォルトのイベントハンドラ > が登録されているIDに上書きしてしまうことができる。 > 改善策）lkst_evhandler_registerの仕様変更、lkst_evhandler_unregister > 　　　　lkst_evhandler_get_idの2つのAPIの追加を行う。 > 　　　　registerに関しては、・システム予約IDへの変更不可、・IDの自動割当 > 　　　　・名前の重複禁止、の3点を中心に行います。 > 　　　　また、これまでNULLを登録することでevhandlerを削除してきましたが > 　　　　専用のunregister関数を使うように変更します。 > 　　　　また、ハンドラに付けた名前からIDを引いてこれるようにget_idを > 　　　　追加します。 > 　　　　この変更についてはこちらで修正済ですが、APIの変更に関して > 　　　　何か問題等ありますでしょうか。 この問題に対するパッチを作りましたので、送ります。 #lkcd抜きのバージョンに対するものなのでいくつかずれがあるかもしれませんが。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: lkst-1.2-evhreg.patch.gz 型: application/x-gzip サイズ: 2396 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/lkst-develop/attachments/20020703/8b0386cd/attachment.bin From akiyama.nobuyuk ＠ soft.fujitsu.com Sun Jul 7 14:17:13 2002 From: akiyama.nobuyuk ＠ soft.fujitsu.com (AKIYAMA Nobuyuki) Date: Sun, 07 Jul 2002 14:17:13 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 References: <3D214C3D.7060402@sdl.hitachi.co.jp> Message-ID: <3D27CED9.7070901@soft.fujitsu.com> 秋山＠富士通と申します． Masami HIRAMATSU wrote: > 日立の平松です。 > > lkst-1.2リリース直後ですが、現状新たに見つかった問題点と改善策 > (修正中のものも含まれます)を明らかにしておきたいと思います。 > ＃すこし長めになってしまいました。 > > (1)lkst_evhandler_register が 与えたIDのイベントハンドラを > 上書き登録してしまう。このため、デフォルトのイベントハンドラ > が登録されているIDに上書きしてしまうことができる。 > 改善策）lkst_evhandler_registerの仕様変更、lkst_evhandler_unregister > 　　　　lkst_evhandler_get_idの2つのAPIの追加を行う。 > 　　　　registerに関しては、・システム予約IDへの変更不可、・IDの自動割当 > 　　　　・名前の重複禁止、の3点を中心に行います。 > 　　　　また、これまでNULLを登録することでevhandlerを削除してきましたが > 　　　　専用のunregister関数を使うように変更します。 > 　　　　また、ハンドラに付けた名前からIDを引いてこれるようにget_idを > 　　　　追加します。 > 　　　　この変更についてはこちらで修正済ですが、APIの変更に関して > 　　　　何か問題等ありますでしょうか。 イベントハンドラの登録ミスを防止するアプローチとして,上記の修正で 特に問題はないと思います． ひとつ教えていただきたいのですが，このような修正を行なおうとした 背景を教えてください. 実際，ハンドラ登録のミスなどによりバグを作りこんだ事例が起こった とか・・・. 問題点が共有できれば,修正方法の議論もし易いと思います． > (2)バッファオーバーライト判定にバグの可能性。 > (3)バッファ解放時に(ロックを取っていないので)アクセスバイオレーションを > 　起こす可能性がある。 > 改善案）LKSTでは、CPU毎に書き込みバッファを持っているので、イベント取得 > 　　　　時にロックを極力省けるのですが、バッファリードやバッファの操作に > 　　　　関しては担当していないCPUからの操作が入ってしまうことになり、上 > 　　　　記のような問題が発生します。そこで、これらのバッファ操作に関しては、 > 　　　　操作を行うプロセスを対象バッファを持つCPU上にmigrateして実行し、 > 　　　　ロックをとらなくてもすむようにしたいと考えています。 > 　　　　具体的には以下のように考えています。 ここで言う「ロック」とは,バッファ操作用のロックのことですか？ イベント取得時にロックしていないため,バッファ削除時のロックが意味を なさないため,削除されたバッファにイベントを書き込む可能性があると言 うことですか？ > (2) > ・リードプロセス(ほとんどの場合lkstlogd)は、set_rmodによって対象CPUに > migrateし > 　リードコマンドを発行する。 > ・読み出しと書き込みが同一CPUのカーネルタスク上で行われるため、オーバー > リード・ > 　オーバーライト判定をしなくてもよい。 バッファ操作をそのバッファが割り当てられたCPUのみで行なうと言う 訳ですね． ここで「set_rmodによって」とあるのですが，この機能を知らないの ですが,どのような機能なのか教えていただけると助かります. また,CPU affinityな機能は,2.4カーネルに入っていましたっけ？ > (3) > ・ カレントバッファでないか調べ、defunctフラグ(atomic)を立て（これは解放 > プロセ > ス中のバッファに、シフトインしないようにするためである）、再びカレント > バッファ > でないか調べる。2度目の確認で失敗したらdefunctフラグを倒してエラーで戻る。 > （このプロセスは、バッファの解放、リストやリングからはずすときにも使われる） > ・その後 バッファ解放プロセスは、cpus_allowedフラグを使ってバッファを使 > うCPUへ > スケジュールされるのを待ち、解放する。 > ・シフトプロセスはdefunctフラグがたっていなければシフトする。 なぜ二重のチェックが必要なのでしょうか？ このあたりのからくり説明をしていただけると非常に助かるのですが. > > (4)デーモンにSIGTERMを送ったときにバッファを二度読んでしまう。 > 改善策）オーバーリードの判定とsignalの判定がうまく働かないために生じる現 > 象ですが、 > 　　　　上記のようにオーバーリード判定が不要になれば自然に治るのではないかと > 　　　　思われます。 > 　　　　また、もう一つの案として、SIGTERMを送ると同時にバッファシフトさ > せると > 　　　　いう方法が考えられています。 「バッファオーバリード判定」と「SIGTERM」の関係が良く理解できて いないのですが,両者ともデーモン内での処理のことですよね？ もう少し原因を具体的に説明していただけると助かるのですが... -- 秋山 延幸(AKIYAMA Nobuyuki) 富士通株式会社 沼津工場(D棟4F) Linux統括部)BCCプロジェクト推進部 E-mail:akiyama.nobuyuk ＠ soft.fujitsu.com Tel:055-924-7241(7551-5721) From ke-hata ＠ sdl.hitachi.co.jp Tue Jul 9 15:25:58 2002 From: ke-hata ＠ sdl.hitachi.co.jp (Keisuke Hatasaki) Date: Tue, 09 Jul 2002 15:25:58 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 In-Reply-To: <3D27CED9.7070901@soft.fujitsu.com> References: <3D27CED9.7070901@soft.fujitsu.com> Message-ID: <200207090625.AA00206@fobos.sdl.hitachi.co.jp> to 秋山様 畑崎＠日立です。 >秋山＠富士通と申します． > >Masami HIRAMATSU wrote: > >> 日立の平松です。 >> >> lkst-1.2リリース直後ですが、現状新たに見つかった問題点と改善策 ・・・・ (skip) ・・・・ >> (4)デーモンにSIGTERMを送ったときにバッファを二度読んでしまう。 >> 改善策）オーバーリードの判定とsignalの判定がうまく働かないために生じる現 >> 象ですが、 >> 　　　　上記のようにオーバーリード判定が不要になれば自然に治るのではないかと >> 　　　　思われます。 >> 　　　　また、もう一つの案として、SIGTERMを送ると同時にバッファシフトさ >> せると >> 　　　　いう方法が考えられています。 > > >「バッファオーバリード判定」と「SIGTERM」の関係が良く理解できて >いないのですが,両者ともデーモン内での処理のことですよね？ > >もう少し原因を具体的に説明していただけると助かるのですが... 　これについては私がお答えします。 　「バッファオーバーリード」とは、書き込みポインタを読み込みポインタが 　追い越してしまうことです。オーバリード中のイベントデータを読み込むと、 　イベントデータが破壊されている可能性があるため、このような判定が 　必要となります。現在、この判定を謝る場合があり、対策を進めています。 　また、「SIGTERM」はデーモンの終了時にデーモンプロセスに対して送ります。 　このとき、デーモン終了時までに書かれたバッファデータを全てファイルに 　落とす作業を行いますが、ここで、まれにバッファの２重読み出しが発生 　しています。これは上記のオーバリード判定不正が原因となっています。 　上記の問題は、あるバッファの読み込作業と書き込み作業が同時に行われる 　場合に発生することが分かっています。そこで、readプロセスのCPUmigrate 　を行うことで回避できます。 From hiramatu ＠ sdl.hitachi.co.jp Tue Jul 9 15:45:44 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Tue, 09 Jul 2002 15:45:44 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 References: <3D214C3D.7060402@sdl.hitachi.co.jp> <3D27CED9.7070901@soft.fujitsu.com> Message-ID: <3D2A8698.8010000@sdl.hitachi.co.jp> 平松＠日立です。 AKIYAMA Nobuyuki wrote: > 秋山＠富士通と申します． > > Masami HIRAMATSU wrote: (snip) > ひとつ教えていただきたいのですが，このような修正を行なおうとした > 背景を教えてください. > 実際，ハンドラ登録のミスなどによりバグを作りこんだ事例が起こった > とか・・・. > 問題点が共有できれば,修正方法の議論もし易いと思います． これはLKSTのコードレビューを行っている際に見つかったものです。 実際に問題となる事例があったわけではありませんが、してほしくない ことを禁止していないのも変だと思いましたので。 >>(2)バッファオーバーライト判定にバグの可能性。 >>(3)バッファ解放時に(ロックを取っていないので)アクセスバイオレーションを >>　起こす可能性がある。 (snip) > ここで言う「ロック」とは,バッファ操作用のロックのことですか？ > イベント取得時にロックしていないため,バッファ削除時のロックが意味を > なさないため,削除されたバッファにイベントを書き込む可能性があると言 > うことですか？ そうです。イベント取得時にロックをかけるとオーバーヘッドが 大きくなってしまうので、ロックをかけずに済ませるために上記の 解決法を提案しています。 >>(2) (snip) > ここで「set_rmodによって」とあるのですが，この機能を知らないの > ですが,どのような機能なのか教えていただけると助かります. set_rmodというのは、イベントバッファから読み出す前に、その プロセス(普通はlkstlogdの読み出しスレッド)がどのCPUのバッファを 読み出すのか、またそのときのフォーマットをPOSIX仕様にするか、 を決めるためのioctlコマンドです。 少し分かりにくいとは思いますが、仕様書(pdf)も参考にしてください。 > また,CPU affinityな機能は,2.4カーネルに入っていましたっけ？ 狙ったCPUにmigrateする機能は、(undocumentedかも知れませんが) 存在します。本来はksoftirqdを実装するためのものですが、タスク 構造体にcpus_allowedというマスキングフラグがあるので、これに 2^nをいれてschedule()を呼び出すと、cpuid = nのCPUで動作する ようになります。 >>(3) (snip) > なぜ二重のチェックが必要なのでしょうか？ > このあたりのからくり説明をしていただけると非常に助かるのですが. shiftイベントは、(1)バッファがいっぱいであり、(2)次に遷移できる バッファが存在する、とイベントハンドラ内部(正確には書き込み用 関数部)で自動的に発生します。(もちろんこの機能を無効にすることも 可能ですが。) そうすると、migrateする前のタスクがcurrentフラグを確認して、次に defunctフラグを立てるまでの間に、何らかのイベントが発生し、 次いでshiftイベントが発生する可能性があります。(非常にまれです) このため、defunctを立てた後に、さらにもう一度確認する必要がある わけです。 #もちろん、migrateしてからdefunctフラグを立てればこのような問題は #無いですが、schedulingに時間がかかりそうなので、このようにして #います。 ##こうしておけば、BHに入れる、という応用も利きそうなので:-) 最後の質問には畑崎さんが答えていますので、 そちらを参照していただけますか。(^^; -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 From akiyama.nobuyuk ＠ soft.fujitsu.com Thu Jul 11 22:30:07 2002 From: akiyama.nobuyuk ＠ soft.fujitsu.com (AKIYAMA Nobuyuki) Date: Thu, 11 Jul 2002 22:30:07 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 References: <3D214C3D.7060402@sdl.hitachi.co.jp> <3D27CED9.7070901@soft.fujitsu.com> <3D2A8698.8010000@sdl.hitachi.co.jp> Message-ID: <3D2D885F.1050204@soft.fujitsu.com> 平松様 秋山です。 〜略〜 >>>(2) >>> > (snip) > >>ここで「set_rmodによって」とあるのですが，この機能を知らないの >>ですが,どのような機能なのか教えていただけると助かります. >> > > set_rmodというのは、イベントバッファから読み出す前に、その > プロセス(普通はlkstlogdの読み出しスレッド)がどのCPUのバッファを > 読み出すのか、またそのときのフォーマットをPOSIX仕様にするか、 > を決めるためのioctlコマンドです。 > 少し分かりにくいとは思いますが、仕様書(pdf)も参考にしてください。 ioctl の LKST_IOC_BUFFER_SETRMOD コマンドのことですね。 この処理の中で CPU migrate するようにすると。 lkstlogd は、CPU数分のプロセスを fork しているようなので、 ロックを省いてもうまく動きそうです。 ですが、ひとつのプロセスから複数のバッファを読み出すよう なプログラムをユーザが作成した場合には、最後に呼び出した LKST_IOC_BUFFER_SETRMOD コマンドで migrate された CPU か ら読み出すことになり、意図したようなシリアライズは行なわ れません。このため、ロックを省くことができないと思います。 バッファにくくりつけのカーネルスレッドですべてのバッファ 操作を行なうようにするなどを考える必要があると思いますが。 >>また,CPU affinityな機能は,2.4カーネルに入っていましたっけ？ >> > > 狙ったCPUにmigrateする機能は、(undocumentedかも知れませんが) > 存在します。本来はksoftirqdを実装するためのものですが、タスク > 構造体にcpus_allowedというマスキングフラグがあるので、これに > 2^nをいれてschedule()を呼び出すと、cpuid = nのCPUで動作する > ようになります。 これ(cpus_allowed)は、そんなに便利な機能なのですか？ やはり、IPI を使うということですよね？ 再スケジュール要求をターゲットCPUに通知しなければならないのです から・・・ #smp_send_rescheduleを投げればいいような気がしますが、 #現タスクがアクティブな状態で投げてもいいのかが分かりませんが。 これは、2.5系へのリベースを念頭においているのでしょうか？ >>>(3) >>> > (snip) > >>なぜ二重のチェックが必要なのでしょうか？ >>このあたりのからくり説明をしていただけると非常に助かるのですが. >> > > shiftイベントは、(1)バッファがいっぱいであり、(2)次に遷移できる > バッファが存在する、とイベントハンドラ内部(正確には書き込み用 > 関数部)で自動的に発生します。(もちろんこの機能を無効にすることも > 可能ですが。) > そうすると、migrateする前のタスクがcurrentフラグを確認して、次に > defunctフラグを立てるまでの間に、何らかのイベントが発生し、 > 次いでshiftイベントが発生する可能性があります。(非常にまれです) > このため、defunctを立てた後に、さらにもう一度確認する必要がある > わけです。 > > #もちろん、migrateしてからdefunctフラグを立てればこのような問題は > #無いですが、schedulingに時間がかかりそうなので、このようにして > #います。 > ##こうしておけば、BHに入れる、という応用も利きそうなので:-) shift時には、イベント自体をspinlockした方が良いのではと 思いますが、それでは性能がでないと言うことでしょうか？ -- 秋山 延幸(AKIYAMA Nobuyuki) 富士通株式会社 沼津工場(D棟4F) Linux統括部)BCCプロジェクト推進部 E-mail:akiyama.nobuyuk ＠ soft.fujitsu.com Tel:055-924-7241(7551-5721) From akiyama.nobuyuk ＠ soft.fujitsu.com Fri Jul 12 14:40:24 2002 From: akiyama.nobuyuk ＠ soft.fujitsu.com (AKIYAMA Nobuyuki) Date: Fri, 12 Jul 2002 14:40:24 +0900 Subject: [Lkst-develop] 性能測定結果と改善案 Message-ID: <3D2E6BC8.5080503@soft.fujitsu.com> 秋山です。 WebBench を使った性能測定を行ないました。 結果と今後の改善案を示します。ご意見いただきたく。 [測定環境] ・サーバ：Pen3(700MHz) Xeon × 4CPU, メモリ1Gバイト ・クライアント数：32クライアント [測定結果] 　1秒間のリクエスト処理数をもとに、pure kernel に対する 　オーバヘッドを算出した。 Req./sec Overhead 　pure kernle 5030 - 　LKST V1.1 4403 12.5% LKST V1.2 4635 7.2% LKST V1.2 off 4911 2.4% 参考）LTT 3215 36.1% 　LKST V1.1 -> V1.2 で、 5.3% の改善。 [目標性能] 　トレース採取時で、5%以下としたい。 　また、トレース採取なしの場合で、1%程度。 [改善案] ・デフォルト採取イベントの見直し(削減)　 　定常的に採取すべきイベントを見直し、削減する。 　削減の方針としては、カーネルデバッグに必要なもののみを 　残し、それ以外はデフォルトから外す。 ・インライン版HOOKマクロの改良 　インライン版は関数版に比べて走行ステップが多く、使用頻 　度も高いと思われる。改良し、走行ステップを減らす。 ・spinlockマクロのオプション化 　spinlockマクロは、SMPカーネルで頻繁に動作するため、トレ 　ースを採取しない場合でも性能負担になっていると思われる。 　デフォルトでは、HOOK を入れず、kernel config 時に HOOK 　を入れるかどうかを選択(ex.Spinlock debugging)するように する。 以上 -- 秋山 延幸(AKIYAMA Nobuyuki) 富士通株式会社 沼津工場(D棟4F) Linux統括部)BCCプロジェクト推進部 E-mail:akiyama.nobuyuk ＠ soft.fujitsu.com Tel:055-924-7241(7551-5721) From hiramatu ＠ sdl.hitachi.co.jp Fri Jul 12 15:11:58 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Fri, 12 Jul 2002 15:11:58 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 References: <3D214C3D.7060402@sdl.hitachi.co.jp> <3D27CED9.7070901@soft.fujitsu.com> <3D2A8698.8010000@sdl.hitachi.co.jp> <3D2D885F.1050204@soft.fujitsu.com> Message-ID: <3D2E732E.80209@sdl.hitachi.co.jp> 平松＠日立です。 AKIYAMA Nobuyuki wrote: > 秋山です。 どうもです。 >>>>(2) (snip) > lkstlogd は、CPU数分のプロセスを fork しているようなので、 > ロックを省いてもうまく動きそうです。 > > ですが、ひとつのプロセスから複数のバッファを読み出すよう > なプログラムをユーザが作成した場合には、最後に呼び出した > LKST_IOC_BUFFER_SETRMOD コマンドで migrate された CPU か > ら読み出すことになり、意図したようなシリアライズは行なわ > れません。このため、ロックを省くことができないと思います。 > > バッファにくくりつけのカーネルスレッドですべてのバッファ > 操作を行なうようにするなどを考える必要があると思いますが。 その方法はこちらでも検討いたしました。 本来なら、kstlogd_CPU*などを作って、ディスクへの書き込みまで 行わせるのが一番妥当だと思いますが、今の時点でそこまで大風呂敷を 広げた場合、実装が間に合うのか、という問題があるんですよね;< あくまで将来の目標として、このアイデアはとっておき、現時点で 最小の変更で最大の効率を上げるために、ユーザプロセスとしては、 set_rmodでCPUを指定して読み出してください、という縛りをつける のは悪くないと思います。 #その上で周り(開発者)を巻き込みながらいい方法を議論し、 #このアイデアも選択肢の一つとして考えておくと。 > これ(cpus_allowed)は、そんなに便利な機能なのですか？ > やはり、IPI を使うということですよね？ > 再スケジュール要求をターゲットCPUに通知しなければならないのです > から・・・ > #smp_send_rescheduleを投げればいいような気がしますが、 > #現タスクがアクティブな状態で投げてもいいのかが分かりませんが。 ksoftirqdの実行部分を見るとわかると思いますが、cpus_allowed を変えた後、migrateするまでschedule()を繰り返すという つくりになっています。;) redhat7.3あたりのLSEのパッチを取り入れたものでは、set_cpus_allowed という関数が用意されています。(一旦タスクをinactiveにした後、 wakeupさせるらしいです) > これは、2.5系へのリベースを念頭においているのでしょうか？ 特に念頭に置いたつもりはないのですが、softirqdの仕組みが 変更されるとは思えません。kernel内部でCPUmigrateする機能は 必要になるだろうと思います。 実装方法はその場その場で変わると思いますが、基本的に CPUmigrateする、というアイデアは将来の(kernelの)リリース でも使えると思います。 >>>>(3) > shift時には、イベント自体をspinlockした方が良いのではと > 思いますが、それでは性能がでないと言うことでしょうか？ イベントのspinlockをすることになると、イベントが起きるたびに trylockすることになり、それはそれで時間を食ってしまいます。 また、shiftを行っている間のイベントの取得が出来ないのは 問題があると思います。 しかしよくよく考えるとdefunctを立てる前のcurrent確認は 不要ですね(笑)。defunctを立ててから、改めてcurrent(もしくは 消せるのか)の確認をすれば事足りました。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 From hiramatu ＠ sdl.hitachi.co.jp Tue Jul 16 19:11:11 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Tue, 16 Jul 2002 19:11:11 +0900 Subject: [Lkst-develop] lkstの現状の問題と解決案 References: <3D214C3D.7060402@sdl.hitachi.co.jp> <3D228BB9.50400@sdl.hitachi.co.jp> Message-ID: <3D33F13F.9050101@sdl.hitachi.co.jp> 平松＠日立です。 前回のパッチにはevhandlerの名前が空でも登録できてしまう 問題がありましたので、修正したものを送ります。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 -------------- next part -------------- 文字コード指定の無い添付文書を保管しました... 名前: lkst-1.2-evhreg-fixed.patch URL: http://lists.sourceforge.jp/mailman/archives/lkst-develop/attachments/20020716/f7531b96/attachment.txt From hiramatu ＠ sdl.hitachi.co.jp Wed Jul 17 14:49:47 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Wed, 17 Jul 2002 14:49:47 +0900 Subject: [Lkst-develop] LKST v1.2の不具合 Message-ID: <3D35057B.3010802@sdl.hitachi.co.jp> 平松＠日立です。 LKST v1.2のパッケージですが、幾つか不具合を見つけました。 1. addonsのmakeに失敗する。 addonsにあるlkst_mod_event_count.cのコンパイル時に、 マクロの引数の数が合わないためにエラーが起きます。 lkst_events.hがらみの問題ではありますが、一時的に 本文最後のパッチを当てて修正できます。(畑崎氏作) #ついでながら、一部bugfixも加えました。 2．RPMパッケージに関する問題 2.a) SPECファイル名にバージョンがついている RedHat本家の方式でも、SPECファイルは パッケージ名.spec です。バージョンを付けることにあまり意味がないようなら とってしまってはいかがでしょうか。 2.b) SPECファイルのchangelogが未更新 SPECファイルの%changelog以下は、パッケージのリリースが 変わるたびに書き足したほうが、後で見てわかりやすくなる と思います。 RPMに関しては、lkcdがらみの部分を別パッケージに分けても いいのではないかと思います。 たとえば lkstutils-lkcd-plugin-1.2-1.i386.rpm が 別個に生成されるなどという案はいかがでしょうか？ -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 #添付にすると、webのアーカイブで見たときに本文まで化けて #しまうようです... --- lkst_mod_event_count.c Wed Jul 17 14:28:24 2002 +++ lkst_mod_event_count.c.new Wed Jul 17 14:26:44 2002 @@ -41,7 +41,8 @@ #define LKST_ETYPE_DEF_ENUM_BEGIN \ typedef enum { -#define LKST_ETYPE_DEF(event_type, prio, hooktype, mnemonic, description) \ +#define LKST_ETYPE_DEF(event_type, prio, hooktype, mnemonic, description,EVENT_NAME_STRING,\ + DISPLAY_FILTER,EVENT_ARG1,EVENT_ARG2,EVENT_ARG3,EVENT_ARG4 ) \ LKST_ETYPE_SERIAL_##mnemonic, #define LKST_ETYPE_DEF_ENUM_END \ @@ -58,7 +59,8 @@ #define LKST_ETYPE_DEF_ENUM_BEGIN \ static const short entry_index_offset [] = { -#define LKST_ETYPE_DEF(event_type, prio, hooktype, mnemonic, description) \ +#define LKST_ETYPE_DEF(event_type, prio, hooktype, mnemonic, description,EVENT_NAME_STRING,\ + DISPLAY_FILTER,EVENT_ARG1,EVENT_ARG2,EVENT_ARG3,EVENT_ARG4 ) \ [(event_type)] = LKST_ETYPE_SERIAL_##mnemonic, #define LKST_ETYPE_DEF_ENUM_END \ @@ -129,7 +131,7 @@ continue; /* readp points entry #1 */ - bufferp->readp = sizeof(struct lkst_event_record); + bufferp->readp = 0 ; //sizeof(struct lkst_event_record); bufferp->last_recid = event_entry_p->log_recid = 0; } From akiyama.nobuyuk ＠ soft.fujitsu.com Wed Jul 17 16:48:44 2002 From: akiyama.nobuyuk ＠ soft.fujitsu.com (AKIYAMA Nobuyuki) Date: Wed, 17 Jul 2002 16:48:44 +0900 Subject: [Lkst-develop] 性能測定結果と改善案 References: <3D2E6BC8.5080503@soft.fujitsu.com> Message-ID: <3D35215C.9020205@soft.fujitsu.com> 秋山です。 性能測定した条件について補足します。 LKST(V1.1および1.2) は、ファイルへのロギングを行わずに 測定してます(ログデーモン lkstlogd は未起動)。 これは、LKSTを定常的に運用する場合で、最も性能が重要視 される使用方法です。 一方、参考に載せました LTT については、ファイルへのロギ ング(実際の出力先は /dev/null )を行なっており、LKSTの測 定条件とは異なります。 これは、LTTでトレース採取する場合には、必ずファイルへロ ギングしなければならない仕様のためです。 LTTのデータは、類似機能の参考データとしてご覧下さい。 以上 AKIYAMA Nobuyuki wrote: > 秋山です。 > > WebBench を使った性能測定を行ないました。 > 結果と今後の改善案を示します。ご意見いただきたく。 > > [測定環境] > ・サーバ：Pen3(700MHz) Xeon × 4CPU, メモリ1Gバイト > ・クライアント数：32クライアント > > [測定結果] > 　1秒間のリクエスト処理数をもとに、pure kernel に対する > 　オーバヘッドを算出した。 > > Req./sec Overhead > 　pure kernle 5030 - > 　LKST V1.1 4403 12.5% > LKST V1.2 4635 7.2% > LKST V1.2 off 4911 2.4% > 参考）LTT 3215 36.1% > > 　LKST V1.1 -> V1.2 で、 5.3% の改善。 > > [目標性能] > 　トレース採取時で、5%以下としたい。 > 　また、トレース採取なしの場合で、1%程度。 > > [改善案] > ・デフォルト採取イベントの見直し(削減)　 > 　定常的に採取すべきイベントを見直し、削減する。 > 　削減の方針としては、カーネルデバッグに必要なもののみを > 　残し、それ以外はデフォルトから外す。 > > ・インライン版HOOKマクロの改良 > 　インライン版は関数版に比べて走行ステップが多く、使用頻 > 　度も高いと思われる。改良し、走行ステップを減らす。 > > ・spinlockマクロのオプション化 > 　spinlockマクロは、SMPカーネルで頻繁に動作するため、トレ > 　ースを採取しない場合でも性能負担になっていると思われる。 > 　デフォルトでは、HOOK を入れず、kernel config 時に HOOK > 　を入れるかどうかを選択(ex.Spinlock debugging)するように > する。 > > 以上 > > -- 秋山 延幸(AKIYAMA Nobuyuki) 富士通株式会社 沼津工場(D棟4F) Linux統括部)BCCプロジェクト推進部 E-mail:akiyama.nobuyuk ＠ soft.fujitsu.com Tel:055-924-7241(7551-5721) From hiramatu ＠ sdl.hitachi.co.jp Tue Jul 23 16:04:18 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Tue, 23 Jul 2002 16:04:18 +0900 Subject: [Lkst-develop] LKST v1.2の不具合 References: <3D35057B.3010802@sdl.hitachi.co.jp> Message-ID: <3D3CFFF2.6030903@sdl.hitachi.co.jp> 平松@日立です。 Masami HIRAMATSU wrote: > LKST v1.2のパッケージですが、幾つか不具合を見つけました。 中村氏が新たに不具合を指摘してくれました。 > <現象> > lkstlogdが正しく終了しない。 > >> ./lkstlogd -a >> kill -TERM `cat /var/run/lkstlogd.pid ` > > lkstlogd error: ioctl(LKST_IOC_BUFFER_DELETE) error: Device or resource busy > > <原因> > ioctlの返り値を負数にした際の修正漏れ。 > restore_buffer()内でioctl(LKST_IOC_BUFFER_DELETE)を発行し、EBUSYが > 返ってきた場合buffer_shift後retryする様になっている。 > しかし、従来のままret==EBUSYで判定しているため、異常終了している。 明らかなバグでしたので、修正パッチを本文の後に追加します。 同時に細かい修正も2箇所入れました。 utilに含まれる他のプログラムには、同様のバグはありませんでした。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346 diff -Naru lkstutils-1.2/lkstlogd.c lkstutils-1.2.fixed/lkstlogd.c --- lkstutils-1.2/lkstlogd.c Fri Jun 28 21:35:22 2002 +++ lkstutils-1.2.fixed/lkstlogd.c Tue Jul 23 11:23:07 2002 @@ -516,6 +516,10 @@ lp.listent_size = LKST_BUFFER_LISTENT_SIZE(LKST_BUFFER_TBL_MAX); lp.listent = listent; ret = ioctl(devfd, LKST_IOC_BUFFER_LIST, &lp); + if (ret) { + fprintf(stderr, "lkstlogd error: ioctl(LKST_IOC_BUFFER_LIST) error: %s\n", strerror(errno)); + exit(1); + } for (i=0; i0; i++) { for (k = 0; k < LKST_BUFFER_TBL_MAX; k++) { @@ -548,12 +552,14 @@ for (j=0; j Message-ID: <3D3D4001.5080106@soft.fujitsu.com> 秋山です。 Masami HIRAMATSU wrote: > 平松＠日立です。 > > LKST v1.2のパッケージですが、幾つか不具合を見つけました。 > > 1. addonsのmakeに失敗する。 > addonsにあるlkst_mod_event_count.cのコンパイル時に、 > マクロの引数の数が合わないためにエラーが起きます。 > lkst_events.hがらみの問題ではありますが、一時的に > 本文最後のパッチを当てて修正できます。(畑崎氏作) > #ついでながら、一部bugfixも加えました。 v1.2でのLKST_ETYPE_DEFマクロの修正ミス（漏れ）ですね。 > 2．RPMパッケージに関する問題 > > 2.a) SPECファイル名にバージョンがついている > RedHat本家の方式でも、SPECファイルは パッケージ名.spec > です。バージョンを付けることにあまり意味がないようなら > とってしまってはいかがでしょうか。 確かに、RedHatのパッケージはそのようですね(apacheを見た限り)。 一方、RPMのHOWTO(http://www.rpm.org/RPM-HOWTO/)では、バージ ョンを付けることを推奨しています。 SPECファイルにバージョンを付けないと、同一機能で異なるバージ ョンを複数インストールした場合、現在どのバージョンのSPECファイ ルが有効なのかファイル名からは判断ができなくなります(中身を見 ればすぐわかりますが)。 また、古いバージョンでのパッケージの再作成の時に、SPECファイル が残っていたほうが便利なので現状のままの方がよいと思います。 #でも、これだと異端になってしまうかもしれませんね。 > > 2.b) SPECファイルのchangelogが未更新 > SPECファイルの%changelog以下は、パッケージのリリースが > 変わるたびに書き足したほうが、後で見てわかりやすくなる > と思います。 そうですね。今後追加しましょう。 > RPMに関しては、lkcdがらみの部分を別パッケージに分けても > いいのではないかと思います。 > たとえば lkstutils-lkcd-plugin-1.2-1.i386.rpm が > 別個に生成されるなどという案はいかがでしょうか？ > 他の機能依存部分なので、別れていた方がよいですね。 HOOKマクロのパッチをLKSTパッチから分離する時に検討します。 -- 秋山 延幸(AKIYAMA Nobuyuki) 富士通株式会社 沼津工場(D棟4F) Linux統括部)BCCプロジェクト推進部 E-mail:akiyama.nobuyuk ＠ jp.fujitsu.com Tel:055-924-7241(7551-5721) From hiramatu ＠ sdl.hitachi.co.jp Wed Jul 24 11:58:50 2002 From: hiramatu ＠ sdl.hitachi.co.jp (Masami HIRAMATSU) Date: Wed, 24 Jul 2002 11:58:50 +0900 Subject: [Lkst-develop] LKST v1.2の不具合 References: <3D35057B.3010802@sdl.hitachi.co.jp> <3D3D4001.5080106@soft.fujitsu.com> Message-ID: <3D3E17EA.5010308@sdl.hitachi.co.jp> 平松＠日立です。 AKIYAMA Nobuyuki wrote: > 秋山です。 > >>2．RPMパッケージに関する問題 >> >>2.a) SPECファイル名にバージョンがついている >> RedHat本家の方式でも、SPECファイルは パッケージ名.spec >> です。バージョンを付けることにあまり意味がないようなら >> とってしまってはいかがでしょうか。 > > 確かに、RedHatのパッケージはそのようですね(apacheを見た限り)。 > 一方、RPMのHOWTO(http://www.rpm.org/RPM-HOWTO/)では、バージ > ョンを付けることを推奨しています。 > SPECファイルにバージョンを付けないと、同一機能で異なるバージ > ョンを複数インストールした場合、現在どのバージョンのSPECファイ > ルが有効なのかファイル名からは判断ができなくなります(中身を見 > ればすぐわかりますが)。 SPECファイル名がバージョン番号を持たない理由を、明確に書いている 文章を探した結果、Momonga-Linux(旧KondaraProjects)のSPECファイル ガイダンス http://www.momonga-linux.org/docs/Specfile-Guidance/ja/spec.html#filename に書いてありました。 > Momonga では spec ファイルを CVS に突っ込んで管理しているため、 > ファイル名にバージョン番号が含まれていると、異なるモノとして > 扱われてしまう。これを避けるためである。 結局、他のプロジェクトでもCVSを使って管理すると、ファイル名を ベースにして管理されるため、SPECファイルを同一名称で統一したほうが 管理がしやすくなるということらしいです。 LKSTの方でもCVSにSPECファイルを登録して管理してはどうでしょうか。 そうすれば古いリリースを直接取り出すことも可能だと思うのですが。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiramatu ＠ sdl.hitachi.co.jp (外線)044-959-0258 (内線)8-69-3346