Mona/0.3.0/分析


TAKAさんによる提案

カーネルのリファクタリング(まだそんな時期ではないかもしれないが)を

考えるのならばまずこの2つから始めてみてはどうだろうか。どちらの機能も

全てのプロセスのパフォーマンスに直結するので改善する余地はあると思う。

PageManager.cppに関して

  1. 関数のオーバーロードがたくさんあってわかりにくい。
  2. 空ページの確保にアルゴリズム的に時間がかかりすぎる。
        1. 現行のアルゴリズムでは0番から順に空のページを探している
        2. 従って、空きメモリなし→ページングへのステップに時間がかかる
        3. ただ、4MB程度だと1024ページなのでそれほど目くじらを立てるほどでもないかと。
  3. 実行できるプロセス数に制限がある。

詳しい説明は Mona/0.3.0/分析/PageManager
コメントは コメント/Mona/0.3.0/分析/PageManager
まで。

Scheduler.cppに関して

  1. FOR_EACHやFOR_EACH_Nはわかりにくいのではないか。
  2. Threadクラスがそのままリストのノードになるというのもどうかと思う。
  3. イテレータつきのリストを導入してみてはどうか
  4. スケジューリングがO(N)のコストになっている。
        1. 今のままでは問題にならないかもしれないが、スレッドの数が増えると切り替えだけで
        2. CPU時間を使い果たしてしまいかねない。
        3. 当分シミュレータ上で動かすことを考えるとパフォーマンスに影響が出るのではないか

Process.cppに関して TAKA 2005-04-05 (火) 21:09:16

プロセス(ユーザープロセス)はユーザーモードで動いているときに使用する スタックとシステムコールを実行している間に使用するカーネル用のスタックの 2種類のスタックを持っている。ユーザーモードで使用されるスタックは 適切の確保されるのだが、カーネルモードで使用されるスタックは 物理アドレス0x100000から下位方向に0x1000バイトずつ順番に確保 される仕組みになっている。つまり、プロセスAを起動したとき0x80000から0x1000 バイトのスタックが与えられたとすると、次に起動するプロセスBのスタックは 0x7f000から0x1000バイトとなる。さらに、この段階でプロセスAを終了させても 次のプロセスに与えられるスタックは0x7e000番地からで決してプロセスAの スタック領域であった0x80000番地からではない。

一方、カーネルのコードは0x1200番地から85524バイト存在するが、コードの 終端を16進数で表せば0x16014番地である。さらにこの後にはさまざまな 基本的なサーバープロセスのコードが記述されているので0x1200から0x20000番地 までは何らかのコードが書かれていると考えたほうがいい。つまり、スタック領域 として使用できるのは0x100000 - 0x20000 = 0x80000バイトとなる。これが 多いか少ないかの判断はあると思うが、プロセスを128回起動させると安全な スタック領域を確保できなくなる。

実際にこのことを確かめてみた。 まず、MONA-0.3.0-alphaをqemuで起動させた後BAYGUIにして、GCLOCK.EX5を 10回起動させては全部消し、10回起動させては全部消しという作業を 繰り返した。そして、110から120個目のプロセスとなるGCLOCKを起動させて 終了させていったときMemoryManagerによるカーネルパニックが発生した。 カーネルパニックの発生原因は正確にはわからないが、おそらくこのことが 原因ではないかと思う。

かなり粗い説明になってしまったが、もし詳しい説明が必要なら知らせてください。

システムコール SYSTEMCALL_MEMORY_MAP_GET_SIZEに関して

この関数は指定IDの共有メモリのオブジェクトの大きさを返すものだが、 共有メモリが見つからないときは返ってくる値は不定値になる。 一方、MemoryMap::map()関数がこのシステムコールを用いているが この関数ではオブジェクトが見つからないときの戻り値を0と想定している。 あまり影響はないと思いますがシステムコールのほうを直しておくことを 勧めておきます。

普通こういうのBugtrackに書くよね。

コメント

最新の10件を表示しています。 コメントページを参照

  • Process.cppに関して対処コードを作ってCVS commitしました。設計と実装に短時間しかかけていないのでbuggyですが、ご確認いただければ助かります -- ひげぽん 2005-04-06 (水) 01:00:12
  • あとこういう系のバグを二人で協力しながらつぶしていけたらと思います。良い進め方が見つかればよいのですが。 -- ひげぽん 2005-04-06 (水) 01:16:42
  • 見た感じ何とかなっているような「感じ」がします。この辺のソースコードを見ていると「急いで作った」「機能を追加した」みられ、修正するにはそれぞれのクラスがどのようにして作用するのかを見極めてからでないと出来いないような気がします。 -- TAKA 2005-04-06 (水) 08:40:35
  • 確認ありがとうございます。とりあえず手をつけたということで一歩前進かと思っています。もちろんリファクタリングの必要はありますが。 -- ひげぽん 2005-04-06 (水) 09:08:17
お名前:

MENU

now: 2

リンク


最新の20件
2017-09-29 2017-04-25 2017-01-10 2016-12-11 2016-12-09 2016-10-04 2016-08-14 2016-06-05 2016-05-29 2016-04-15 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: 1976, today: 1, yesterday: 1

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

Last-modified: 2008-03-28 (金) 15:47:55 (3681d);  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.050 sec.