[SCore-users-jp] Score+Scash+OmniMP
長谷川 篤史
a-hasega @ ats.nis.nec.co.jp
2002年 2月 27日 (水) 22:50:38 JST
長谷川@NEC情報システムズです。
佐藤@奈良先端さんのレポートを読み返していて、
128MBの環境で、SCASHが16MBの共有メモリ領域を確保できないのが、
納得できなかったので、確認してみました。
# 私は完全に動作を勘違いしていました。
# まだ、全部追いきれていないので、怪しいところもありますが、
# 今後、Omni/SCASHを使用する場合の参考になると思いますので、
# 詳細をまとめてレポートしておきます。
> メモリに関してですが、
> OMPC_DEBUG=1 ./a.out
> として実行すると、デバッグメッセージとして、
> プログラムが使用する共有メモリ容量を出力します。
> 実行には、最低でも、その倍の物理メモリを必要とします。
> ~~~~
で、結論からいうと、この、倍の物理メモリ必要とするというのは間違い
(私の勘違いか、linux 2.0の頃から仕様が変わったのか)で、
SCASHの共有メモリサイズ * 8 + 1.6MB + α
必要となります。
Omni/SCASHで使用する場合は、
SCASHの共有メモリサイズ = Omni/SCASHが使用するshared変数のサイズ
に置き換えれば計算できます。
この値は、linux-2.2.10 + SCoreのドライバーにデバッグ分を追加して
で動作を確認した結果ですので、kernelのバージョンアップにより改善
される可能性はあります。
で、これだけのメモリが必用になるのは、以下の理由からです。
1. pmMLockは、kernelの動作の安全性から物理メモリの1/2以上の
メモリをロックできないように制限しています。
pm_memory.c で、current->mm->locked_vmとnum_physpagesから
チェックしています。
2. linux のmmapは、マップした領域を、1のpmMLockがチェックに使用する、
current->mm->locked_vmにカウントアップします(MAP_SHAREDの場合だけかも)。
locked_vmへは、マップしている領域分、カウントアップされます。
同じ領域をMAP_SHAREDでmmapしていても、それぞれカウントアップされます。
3. SCASHは、共有メモリサイズ * 3 + テーブル(800KB)をマップします
4. SCASHは、全領域をmmapしたのちに、pmMLockします
5.SCASHは、mmapした領域の一部をpmMLockでロックするのですが、
すでにロックされているサイズ(mmapされた領域+最初からカーネルで
使用されている分)に、今回ロックするサイズを加えた値が、物理メモリサイズ/2
以下なければ、エラーになります。
scashがpmMLockで共有メモリサイズ分をロックするため、
結果として、(共有メモリサイズ*4+800KB+α)*2の物理メモリがないと、
メモリサイズのチェックに引っかかります。
PS. 気になっているところ
もう、kernel 2.4.x に移行するので、いまさら気にしても仕方ないとは思いますが、
今回、SCore 2.4.1に含まれる、kernel 2.2.10(bigmemへのパッチがあたっていないもの)
の、pm_memory.c で、currenet->mm->locked_vm の値をダンプして、値の変化をチェック
していたところ、mmap した時にカウントアップされているようなのですが、do_mlock
でロックしたページが current->mm->locked_vmにカウントアップされていないように
見えるのですが、問題ないのでしょうか? > 亀山さん
カウントアップされないと、いくらでもpmMLockできるような気がするのですが....
--
長谷川 篤史 E-Mail:a-hasega @ ats.nis.nec.co.jp
株式会社NEC情報システムズ 基盤ソフトウェア事業部 サイエンス基盤部
外線:03-3798-9991(Fax.03-3798-9198) / 内線:8-115-2410(Fax.8-115-2419)
SCore-users-jp メーリングリストの案内