議論/プロセス空間


Top / 議論 / プロセス空間

メモリマッピング(ユーザープロセス)案

RangeTYPEKernel-mode R/Wuser-mode R/WRemark
0-1MBUSERR/WR/WFOR V86 ONLY
1-16MBKERNELR/W-FOR DMA
16-512MBKERNELR/W-FOR KERNEL CODE/DATA
512-1024MBUSERR/WR/WFOR IPC&ETC MAPPED WHEN NECESSARY

考えるべきこと

プロセス空間設計(2003/09/19旅先殴り書きメモより)

プロセス生成

  1. プロセス妥当性検査(Maxプロセス、特権レベル、セキュリティ)
  2. ページディレクトリの存在確認
  3. コードデータのコピー(不必要?) copy on read? ELFLoader改良?
  4. スタック割り当て(スタック境界ページ)
  5. ヒープ割り当て(ヒープ管理)
  6. エントリポイントの設定
  7. スイッチ
プロセス(スレッド)構造体にメモリ管理構造体のポインタを持たせる

ページフォルト

  1. コードの範囲でかつ、プロセスサイズ以内ならばディスクから読み込んでコピー(割り込みを許可しながら)
  2. スタック境界のページフォルト。拡張(書き込み不可にしておく)

システムコール時の

  1. ポインタがヒープ、データ以外だったらNG

ヒープ管理簡易版

殴り書きここまで

関連項目洗い出し

実現しなければいけない機能

カーネルを共有部においた場合のメッセージ機構シナリオ

プロセスA(空間A) リニアアドレスX〜Yにカーネルが配置されている(ただし非特権レベルではアクセス不可)
プロセスB(空間B) リニアアドレスX〜Yにカーネルが配置されている(ただし非特権レベルではアクセス不可)
メッセージサーバ(特権レベル)
  1. AはBに対して文字列"Mona"をメッセージ機構を利用して送信したい。
  2. Aは、文字列を空間Aに配置し、システムコールsendを発行する。引数として文字列へのポインタをセットする。
  3. システムコール発行で特権レベルに遷移し、CS,DS,SS等はカーネルのものに変更される。(ただしフラットモデルなのでアドレス変換は発生しない)
  4. ----ここから割り込み許可
  5. 特権レベルでX〜Yに配置されているsend手続きを開始する。
    1. X〜Yのそとにある、文字列"Mona"をX〜Yにコピーする。
    2. プロセスAはrun queueからはずされる。
    3. スケジューラー起動
  6. メッセージサーバーが暇を見てプロセスBに文字列をコピーする。
  7. プロセスBのプロセス構造体(カーネル空間にある)にメッセージ到着マークを付ける
  8. だめだメッセージはpush型にしたいのにプロセスBの空間をいぢれないや。

コメントページを参照

  • メッセージングはプロセス同士を繋ぐ手段なので、その部分は特別扱いする必要が有るのかも。 -- .mjt 2003-08-01 (金) 02:12:29
    • すいません。特別扱いとは具体的に、何と比べてでしょうか。 -- ひげぽん 2003-08-01 (金) 19:13:18
    • #osdev-jでaliceさんが仰っていたように、仮にカーネルのメモリ空間とプロセスのメモリ空間を分離するにしても、メッセージングに関わる部分はどうしても共有部分に置くことになるって事です。 そして、カーネルの主な仕事がメッセージングである以上、カーネルは共有部分に置くことになるのではないかなと。 -- .mjt 2003-08-02 (土) 02:05:10
    • なるほど。最新版Solarisはカーネルとプロセスの空間は完全に分離されているようです。以前のバージョンはメモリ空間は共有されていたようですが、カーネルサイズが制限されてしまうなどデメリットもあったようです。 -- ひげぽん 2003-08-02 (土) 13:05:26
    • また完全に分離されるようになった理由としてCPUの機能で空間の切り替えが非常に高速に行えるようになったことが挙げられるみたいです。 -- ひげぽん 2003-08-02 (土) 13:09:05
    • ただしIA32で空間切り替えがどのくらいコストがかかるかは微妙です。 -- ひげぽん 2003-08-02 (土) 13:11:27
  • カーネルを共有部部においた場合のメッセージ機構シナリオ(書き途中)についてのコメント -- ひげぽん 2003-08-02 (土) 14:04:45
  • 今のMonaは、プロセス間のメモリ空間は、全て共有されているのでしょうか? libのMemoryManagerのソースを見ると、メモリの取得にシステムコールが使われていないように思えるので、ひょっとして分離されていないのかと思ったのですが。 -- 2004-04-25 (日) 09:35:35
  • ページテーブルにメモリが貼り付けられていない領域にアクセスされると、ページフォルトが発生して、そこで、物理メモリを割り当てているはずです。(コードを読むと)で、物理メモリが足りなくなると halt するのかな。 -- 2004-04-25 (日) 10:05:50
  • では共有メモリの窓の位置は、明示的にアプリ側が、MemoryManagerが利用する領域を避ける必要があるのですね。それから、MemoryManagerのgetPhysicalMemorySize()がpublic属性になってますが実際は利用できないのではないでしょうか。 -- 2004-04-25 (日) 10:16:32
  • あと、一度使用して物理メモリが割り当てられれば、物理メモリを解放する手段がないのでしょうか。仮にそうだとすると長時間常駐するアプリがせっかくfree()しても物理メモリがマッピングされたままで問題です。それと、MemoryManagerが使用するサイズが、initialize()で初期化時に固定的に16MB(位?)割り当てられていて、200MB使用するアプリは起動できないし、逆に共有メモリを多用するアプリでは領域の無駄使いになる。 -- 2004-04-25 (日) 10:21:48
  • ページング周りは HDD をサポートするときに手が入るのではないでしょうか。(確保したメモリの解放手段は現在無いと理解しています。また、メモリの使用量も固定のハズです。以下のページも参考になるでしょう。Mona/メモリマッピング (それと、蛇足ですが、このページは議論/プロセス空間から書き込めるので、commentは不要かと思います。 -- 2004-04-25 (日) 10:34:21
  • 思い出したので追加でコメントです。16MB固定で割り振っていても、実際の物理メモリが割り当てられるのはページフォルトが発生したときでは無いでしょうか?つまり、アプリが起動された時点では無駄使いにはなっていないと思います。 -- 2004-04-25 (日) 11:02:40
お名前:

MENU

now: 2

リンク


最新の20件
2018-10-07 2018-09-20 2018-09-03 2018-05-09 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-05-29 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 3273, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:02 (3910d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.098 sec.