[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 メーリングリストの案内