Path: sran265!katsu From: katsu@sran14.sra.co.jp (WATANABE katsuhiro) Message-ID: Date: 17 Nov 92 16:23:23 Organization: Software Research Associates, Inc.,Japan In-reply-to: image@cs.titech.ac.jp's message of 6 Oct 92 05:23:08 GMT Newsgroups: fj.unix,fj.sys.news Subject: Re: Q. about /etc/pstat Distribution: fj References: （Newsgroups: に注意） フォローの遅さなら jp で十指にはいるであろう渡邊＠ＳＲＡです。 記事 で image@cs.titech.ac.jp (Takashi Imaizumi) さんいはく > > （４）まとめ（pstat -x の見方に関する tips） > > ということで、/etc/pstatの出力の見方に関してはこの記事で現時点 > で十分な知識を得ることができました。 　折角ですから、vmstat -s との関係やフラグについての議論もしましょうよ。 4.3BSD に由来する OS について、ソースを見ずにわかった範囲で書きます。 [1] テキスト構造体のフラグと pstat -x について 　pstat -x で普段直接見えるフラグは P と W だと思います。P は XPAGV を、W は XWRIT を (cf. ) 示しています。 　XPAGV は、普通の BSD では magic number が ZMAGIC (cf. ) かどうかを反映しています。 　しかし NEWS-OS の 4.1 以前のものは例外で、ZMAGIC のテキストの うちでテキストの大きさが 106496bytes(26 pages) 以上（さらにいえば、 少なくとも NEWS-OS 3.3 においては 25pages 以上だった）のものに 付きます。このことが、NEWS-OS 4.1 以前では 25pages 以下のテキストは demand load しないことを意味しているのか、それとも他の要因が間接的に XPAGV に現れたものなのかは私には判断がつきません。NEWS-OS の中でも 4.2 では、普通の BSD と同じように、全ての ZMAGIC のテキストに XPAGV がつくようです。 　XWRIT はそのテキストのイメージがスワップに書き出された経験が あるかどうかを示します。一番最初にテキストが起動されたときは セットされており、何らかの原因で１回でも swap out されればクリア されます。 　プロセスが終了して、参照していたテキストがキャッシュに入る ときには、そのテキストのイメージは（まだ swap outされたことが なければ）swap out されますが、当然この時も XWRIT はクリアされます。 よって、キャッシュから呼び戻されて active になったテキストには、 pstat -x で見たときに W フラグがつかないことになります。 　（ところで、プロセスのデータ領域の swap out と、テキストイメージの swap out は別物ですから混同しないよう注意してください。） 　pstat -x からは見えませんが、XUNUSED というフラグもあります。 これは、テキストがキャッシュに入った後、一度でも利用されたことが あるか（キャッシュらしい働きをしたか）どうかを示すためのフラグ です。最初にキャッシュになる時はセットされ、その後一旦 active に なった末に再びキャッシュに入る場合はリセットされ、以降ずっと リセットされたままになります。 　実は、キャッシュに入るのが初めてのテキストでも、active な間に swap out された経験を持つものだと、XUNUSED がセットされません。 このことから、実装上は、テキストがキャッシュに入る時に XWRIT が セットされていると XUNUSED もセットされるようになっているものと 想像されます。 　XUNUSED は統計（後述）には用いられていますが、テキストの扱いに 何か影響を及ぼすものではないようです。 [2] vmstat -s の読み方について 　さて、テキスト構造体のフラグの意味を理解することではじめて vmstat -s の意味もわかるようになります。 　vmstat -s は sum 構造体 (cf. vmstat(8), ) に加えて、 xstats 構造体 (cf.) の内容も表示してくれます。最後の ３行ぐらいで、 AAAA total calls to xalloc (cache hits BB%) sticky CCCC flushed DDDD unused EEEE FFFF total calls to xfree (sticky GGGG cached HHHH swapped IIII) のように出力されるのがそれですが、読み方がマニュアルには書いていない ようなので、ここに紹介します。 　大きく分けて、AAAA から EEEE はテキストエントリーを割り当てようと したときの統計、残りは解放しようとしたときの統計になっています。 (1) AAAA : xstats 構造体の中のメンバー alloc 　テキストエントリーを割り当てようとした、もしくは捜しだそうとした 回数。NMAGIC もしくは ZMAGIC のコマンドに対して execve(2) が呼ばれた 回数に等しいと思われる。 (2) BB : 100 * xstats.alloc_cachehit / xstats.alloc 　テキストエントリーを割り当てる、もしくは捜すときに、求める テキストがテーブル中にキャッシュとして存在していた割合。 (3) CCCC : xstats.alloc_inuse 　求めるテキストが既に他のプロセスに使われていたために、幸運にも テキストテーブル内に active な状態で存在していた回数。 (4) DDDD : xstats.alloc_cacheflush 　キャッシュとなっていたエントリーがが捨てられた回数。 　テキストが新規に起動されたものだったためにキャッシュ中に 見つからず、フリーリストの先頭からエントリーを取ってきたが、 実はそれがキャッシュ中のエントリーとして有効な vnode を 保持していた（そして新しいテキストのために追い出されてしまった） ような場合に増える。 (5) EEEE : xstats.alloc_unused 　(4) の場合のようにキャッシュ中のエントリーが捨てられた時、 そのエントリーに XUNUSED フラグが付いていた回数。つまり、一度も キャッシュらしい働きをしなかったようなテキストキャッシュが 捨てられた回数。 (6) FFFF : xstats.free 　テキストエントリーがプロセスから解放された回数。magic number が NMAGIC や ZMAGIC であるようなプロセスが終了した（させられた）回数に 等しいと思われる。 (7) GGGG : xstats.free_inuse 　テキストがプロセスから解放されたので inactive にしようとしたが、 他にもこのテキストを使っているプロセスがあったために active な ままで残った回数。 (8) HHHH : xstats.free_cache 　テキストエントリーが inactive になった際に、キャッシュとして フリーリストにつながれた回数。 　xstats.free_cache と xstats.free_inuse は排他的な関係にあり、 これらの変数の両方が同時に増加することは状況はあり得ない。 　また、プロセスが終了したときに既に process file が unlink されて いたような場合にも、エントリーはフリーリストにつながれながらも キャッシュにはならないから、このカウンターは増えない。 　さらに、実はカーネルには _maxtextcache という変数があって、 フリーリスト内でキャッシュとして用いられるエントリー数の上限を 押さえることが可能となっており（例えば NEWS-OS 4.X の場合、 通常の構成だと _maxtextcache はテキストテーブルの大きさと 等しくなって何ら効果を及ぼさないが、ディスクレス上で動かす時の ように swap を nfs 上に取るときは 0 になる、といった形で使われて いる模様。この点が 4.3BSD 一般にどうなっているかは不明。）、 この変数の大きさを越えた分はキャッシュに入らず not used なエントリー になる。こうした場合も free_cache は増えない。 　_maxtextcache が十分大きく、また実行ファイルが unlink されない 状況下では、xstats.free_inuse + xstats.free_cache = xstats.free と なるはずである。 (9) IIII : xstats.free_cacheswap 　(8) の場合のようにテキストエントリーがキャッシュになるとき、 そのエントリーの XWRIT がセットされていたためにテキストイメージが swap out された回数。 　例えばいま、コマンド ct のテキストが今まで実行されたことがなくて キャッシュに入っていなかったとする。このとき ct を１回起動して swap out が１度も起きないうちに終了すると、ct のテキストイメージが swap out されるので、xstats.free_cacheswap は増加することになる。 しかし、引き続いて（あまり間隔を置かずに）再度 ct を起動して 終了しても、このカウンターは増加しない。 [3] NEWS-OS 4.2 の特殊性 　NEWS-OS の 4.1 までには [1][2] の知識がよくあてはまりますが、 4.2 では事情が少し違います。わかっている範囲で違いをメモして おきます。（私は普段 NEWS-830 で NEWS-OS 4.2C を使っています） (a) まず、XCACHE というフラグが追加されています。これは、local な ufs 上のテキストでは常にクリアされており、nfs 上のテキストでは 逆に常にセットされているようです。ufs でも nfs でもないファイル システムで XCACHE がどうなるか知っている人は教えてください。 　名前からして、テキストのキャッシングとの関連を想像できます。 そして、呼応するかのように、struct rnode にキャッシング関係の メンバーが追加されてもいます (cf. ) が、無関係かも しれません。 (b) XWRIT フラグの semantics が変わったようです。 　テキストが active の状態で swap out されて XWRIT がリセット された後、 ・（例えばプロセスが kill されるなどで）swap out されたまま inactive になると、XWRIT はリセットされたまま。……… (i) なのはこれまで通りですが、一方で、 ・swap in すると XWRIT が再びセットされる。 ……… (ii) となってしまいます。(ii) はこれまでになかったことです。 　また、キャッシュに入っているテキスト（[1] で述べたように、 XWRIT がリセットされている）が呼び戻されて active になる時、 local なファイルシステム (ufs) のものは、XWRIT が再びセットされて しまいます。これも今までは見られなかったふるまいです。 　さて、XWRIT の semantics の変化は、これと関係が深い XUNUSED や、 ひいては xstats 構造体にも影響を与えました。よって、[2] の (5),(9) 項の説明は適当な読みかえが必要です。 　例えば (9) の例でいうと、コマンド ct がもし local なファイル システムに存在するような場合には、ct の起動終了を繰り返すごとに （起動するたびにXWRIT が毎回セットされるのだから）毎度 xstats.free_cacheswap が増加することになります。 (z)おまけ：NEWS-OS 4.2 には _text_debug というカーネル変数 (int) があって、これが非零だと、少しだけですがテキストテーブルに関する 活動の報告をシステムログに残してくれるようです。 　_???debug という名前からして目立っていますね。しかしこうした 名前の変数のうちでも、original の 4.3BSD に由来せず、なおかつ （デバイス類のようなものでなくて）テキストテーブルのように カーネルの中心的活動に関するデバッグ用の変数が残っていることは 珍しいと感じました。 　それにしても、XCACHE といい、XWRIT や XPAGV の semantics の 変化といい、どうも NEWS-OS 4.2 でどういう変更が行われたのか よくわかりません。まさかとは思いますが、local なファイルシステムに プロセスファイルがあるときは、スワップにテキストイメージを キャッシュするのは止めてしまったなんてことじゃないですよね……… 　どなたかご存じの方は教えてください。 -- 渡邊克宏＠ＳＲＡソフトウェア工学研究所