Mercurial > hg > Game > Cerium
diff TaskManager/ChangeLog @ 1052:a0ea7d9b6faf draft
Makefile utf-8
| author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Fri, 10 Dec 2010 23:09:12 +0900 |
| parents | 4cd17f86dda6 |
| children | 2a63ba2c9506 |
line wrap: on
line diff
--- a/TaskManager/ChangeLog Thu Dec 09 22:30:32 2010 +0900 +++ b/TaskManager/ChangeLog Fri Dec 10 23:09:12 2010 +0900 @@ -1,536 +1,578 @@ +2010-12-10 Shinji KONO <kono@ie.u-ryukyu.ac.jp> + + task_list を PPE の main memory において、それを get_segment で取って来る。 + 実行する object は、PPE 側の main memory 上に置く。それを get_segment で + copy して実行する。 + + taskのindata/outdata/get_segment を実際にはコピーしないようにすると良いのだが... + そうすれば、実行時のアドレスが変わらないのでデバッグが容易。 + そういうオプション? いや、get_segment をそういうようにする? + + task_list 上に固定アドレス task かどうかの選択を入れれば良いのか。 + + とりあえず、task_list を get_segment するところから書くのが良さそう。 + + task_list のaddress を SPE にどうやって教えるかと言う問題がある。 + mail かな。 + + tag 使う? argv で渡すってあり? envp で送れるのではないか? + envp はダメだが、argv では渡せるらしい。 + + まず、ppe と spe の task_list を作る API の設計と実装をするべきらしい。 + + Task 側のは無視 (おぉ?!) SPE 側の SchedRegister も不要。 + + get_segment だけでできる? + + PPE側で、 + + TaskRegister(Task ID, 0 file, entry symbol); // PPE fixed task + SpeTaskRegister(Task ID, object file, entry symbol); // SPE dynamic task + SpeTaskRegister(Task ID, 0, entry symbol); // SPE fixed task + + を指定することになる。 PPE 側は自動的に登録される ( -cpu 0 があるから ) + task_list と spu_task_list が同時に初期化される + + object file は、.a でも良い。(良いの?) embed しても良い。 + + と言うことは、今までのように run を使い回しっ手のいうは許されないってこと? + その方が良いでしょう。変更大きいけど。 + + SPE側に固定する Task はどうするの? + 2010-8-7 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - get_segmentのinlineは、その場に static に置いて、default のものを置いておく。 - size のcheckはしない。 - - MemList は廃止。QueueInfo に。 - - Data 領域は、2^n 管理で、move/compaction を行なう。(が、今は書かない) - - とりあえず、SPUのobject管理だが... + get_segmentのinlineは、その場に static に置いて、default のものを置いておく。 + size のcheckはしない。 + + MemList は廃止。QueueInfo に。 + + Data 領域は、2^n 管理で、move/compaction を行なう。(が、今は書かない) + + とりあえず、SPUのobject管理だが... 2010-8-6 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - Bulk, Simple, basic は一つにするべきだよな。many_task は、sort と言う名前に変えるべき。 + Bulk, Simple, basic は一つにするべきだよな。many_task は、sort と言う名前に変えるべき。 2010-7-31 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - なんと、simple task を SchedTaskManager 経由で作ると、 - PPE task しか作れなくなっていたらしい。それな遅いよ。 - SchedTaskManagerのtask managerがFifoManagerだったのが - 原因。CellTaskManager を使う時には、FifoManagerは消せる? - - その代わり、dead lock が起きる。待ち先のtaskが消滅する場合が - あるらしい。 - - やっぱり、既に終了した task に対して wait for してしまうのが - まずいらしい。自分で HTask をfree してやれば良いわけだが.. + なんと、simple task を SchedTaskManager 経由で作ると、 + PPE task しか作れなくなっていたらしい。それは遅いよ。 + SchedTaskManagerのtask managerがFifoManagerだったのが + 原因。CellTaskManager を使う時には、FifoManagerは消せる? + + その代わり、dead lock が起きる。待ち先のtaskが消滅する場合が + あるらしい。 + + やっぱり、既に終了した task に対して wait for してしまうのが + まずいらしい。自分で HTask をfree してやれば良いわけだが.. 2010-7-30 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - TASK_LIST_MAIL でない方が高速なみたい - sort (many_task) が、とっても遅くなっている + TASK_LIST_MAIL でない方が高速なみたい + sort (many_task) が、とっても遅くなっている 2010-7-24 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - やっぱり、load module のlinkの解決はやらないといけないので、 - 無理に、SchedTaskのAPI全部を virtual にする必要はないらしい。 - spu-gcc spe/ChainCal.o -Wl,-R,spe-main -o tmp.o - と言う形で、link してやれば良い。(ただし、必要なものが参照されている場合) + やっぱり、load module のlinkの解決はやらないといけないので、 + 無理に、SchedTaskのAPI全部を virtual にする必要はないらしい。 + spu-gcc spe/ChainCal.o -Wl,-R,spe-main -o tmp.o + と言う形で、link してやれば良い。(ただし、必要なものが参照されている場合) 2010-7-16 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - SimpleTask のsizeを16の倍数に。そうしないと、Taskのaligmentが16に - ならないので、gcc -O9 で破綻する。 + SimpleTask のsizeを16の倍数に。そうしないと、Taskのaligmentが16に + ならないので、gcc -O9 で破綻する。 2010-7-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - SchedTaskArray::exec の run の値が最適化で、おかしくなるのは、gcc のbugらしい。 - SimpleTask の finish mail が返るのが早すぎる。write を呼ぶのが正しい。 - cur_index++ してしまうと、task1/task2 のcur_indexが同じになってしまう。 + SchedTaskArray::exec の run の値が最適化で、おかしくなるのは、gcc のbugらしい。 + SimpleTask の finish mail が返るのが早すぎる。write を呼ぶのが正しい。 + cur_index++ してしまうと、task1/task2 のcur_indexが同じになってしまう。 2010-5-25 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - PPE側のpost_funcやtaskを実行している時にもSPEからのメールは読んでしまう - のが望ましい。読んで、とりあえずfifoに入れておく。その場で処理しても良いが、 - check_task_list_finishとかが再帰的に呼びされるのがやっかい。 - - Task 実行ループは Scheduler にpoling routineを登録するのが良さそう。 - post_func は、SchedTask 経由で poling すれば良い。 + PPE側のpost_funcやtaskを実行している時にもSPEからのメールは読んでしまう + のが望ましい。読んで、とりあえずfifoに入れておく。その場で処理しても良いが、 + check_task_list_finishとかが再帰的に呼びされるのがやっかい。 + + Task 実行ループは Scheduler にpoling routineを登録するのが良さそう。 + post_func は、SchedTask 経由で poling すれば良い。 2010-5-22 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - CpuThread を作るなら、create_task は、manager にメールで教えないとだめ。 - CpuManager みたいなものを用意しないとダメか。 - - HTask から、waitfor/create_task とかは、TaskManager を呼んでいる。 - そのたびに CAS (Check and set) するのはばかげているよな〜 - TaskManager にメールで送る方が良いのではないか。 - - wait_for する Task が既に終了していると、存在しないTaskあるいは、 - 別な Task を wait_for する場合がある。いわゆるゾンビだけど、これは - どうしよう? 生きているかどうかを識別するように id を付けるか? - - どうも、TaskManager.{h,cc} は要らないっぽい。TMmain に渡されるのも - SchedTask である方が自然。 - - TaskListInfo は循環リストなので、SPU/PPU scheduler に渡す前に、 - getLast()->next = 0 する必要がある。freeAll() する前に、直さないと - だめ。getList() みたいなものを用意しても良いが... - - Scheduler のconnector(DMA) / Memory 関連は Scheduler.{h,cc} から - 追い出すべき。connector/memory とかを SchedTask に持たせれば良い。 - そうすると、API追加でScheduelr.{h,cc} / TaskManagerImple とかを修正する - 必要がなくなる。 + CpuThread を作るなら、create_task は、manager にメールで教えないとだめ。 + CpuManager みたいなものを用意しないとダメか。 + + HTask から、waitfor/create_task とかは、TaskManager を呼んでいる。 + そのたびに CAS (Check and set) するのはばかげているよな〜 + TaskManager にメールで送る方が良いのではないか。 + + wait_for する Task が既に終了していると、存在しないTaskあるいは、 + 別な Task を wait_for する場合がある。いわゆるゾンビだけど、これは + どうしよう? 生きているかどうかを識別するように id を付けるか? + + どうも、TaskManager.{h,cc} は要らないっぽい。TMmain に渡されるのも + SchedTask である方が自然。 + + TaskListInfo は循環リストなので、SPU/PPU scheduler に渡す前に、 + getLast()->next = 0 する必要がある。freeAll() する前に、直さないと + だめ。getList() みたいなものを用意しても良いが... + + Scheduler のconnector(DMA) / Memory 関連は Scheduler.{h,cc} から + 追い出すべき。connector/memory とかを SchedTask に持たせれば良い。 + そうすると、API追加でScheduelr.{h,cc} / TaskManagerImple とかを修正する + 必要がなくなる。 2010-5-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - speTaskList_bg は追放するべきだと思われる。(done) - - PPE task はTaskList をすべて実行するまで戻って来ない。 - なので、spe のmail checkが疎かになっている。 - PPE task の実行途中で SPEのmail checkを行なうべき。 - - Fifo/Cell TaskManagerImpl は統一できるのではないか? (done) - - SchedTask は今は各Taskのselfを返しているがTaskListにするべき - spe からのメールはTaskListが空になった時で良い。早めに、 - - PPE Taskを早めに起動する義理はある? あるかも知れない。Quick Reply Property。 - - TaskList もDataSegement化するべきだと思われる。(done) - - Scheduler::task_list もDataSegment化して、メインメモリ上に置く。 + speTaskList_bg は追放するべきだと思われる。(done) + + PPE task はTaskList をすべて実行するまで戻って来ない。 + なので、spe のmail checkが疎かになっている。 + PPE task の実行途中で SPEのmail checkを行なうべき。 + + Fifo/Cell TaskManagerImpl は統一できるのではないか? (done) + + SchedTask は今は各Taskのselfを返しているがTaskListにするべき + spe からのメールはTaskListが空になった時で良い。早めに、 + + PPE Taskを早めに起動する義理はある? あるかも知れない。Quick Reply Property。 + + TaskList もDataSegement化するべきだと思われる。(done) + + Scheduler::task_list もDataSegment化して、メインメモリ上に置く。 2010-4-28 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - SchedTaskBase のみにインスタンス変数を書かせて、 - SchedTask*.h には method のみを書かせる。 - そうすると、デバッグが楽だし、object のallocateも楽。(done) - - HTask(list) -> TaskList(array) -> SchedTask - - というcopyだが、SchedTask で最初から作る方が良いのかも。 - それを DataSegment で共有する。 - - SimpleTask のMailを、 - if (mail_is_not_full) send_mail() ; - else if (queue is not full) enqueuue() ; - else wait_mail(); - ってな感じに出来ないの? - - Multi thread にすると、PPEのmail loop が暴走する可能性がある。 - このあたりなんか方法があるはずだが... + SchedTaskBase のみにインスタンス変数を書かせて、 + SchedTask*.h には method のみを書かせる。 + そうすると、デバッグが楽だし、object のallocateも楽。(done) + + HTask(list) -> TaskList(array) -> SchedTask + + というcopyだが、SchedTask で最初から作る方が良いのかも。 + それを DataSegment で共有する。 + + SimpleTask のMailを、 + if (mail_is_not_full) send_mail() ; + else if (queue is not full) enqueuue() ; + else wait_mail(); + ってな感じに出来ないの? + + Multi thread にすると、PPEのmail loop が暴走する可能性がある。 + このあたりなんか方法があるはずだが... 2010-4-24 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - write T3 T2 T1 TL TA0 TA1 - exec T2 T1 TL TA0 TA1 TA2 - read T1 TL TA TA1 TA2 T2 - next T1 TL TA TA1 TA2* T2 - - *のところで終了mailが出てTaskArrayのデータがfreeされてしまうので、よくない - そうならないように、一段TAN(SchedTaskArrayNop)を挟む。 - - write T3 T2 T1 TL TA0 TA1 TA2 TAN% - exec T2 T1 TL TA0 TA1 TA2 TAN T2 - read T1 TL TA TA1 TA2 TAN T2 T3 - next T1 TL TA TA1 TA2 TAN T2 T3 - - %のところで終了mailを送る。T2のreadのところで、TaskArrayのデータはreadbuff上にあるので - 破壊されてしまう。なので、savedTask->task->self の値はTANにコピーして持っていく必要がある + write T3 T2 T1 TL TA0 TA1 + exec T2 T1 TL TA0 TA1 TA2 + read T1 TL TA TA1 TA2 T2 + next T1 TL TA TA1 TA2* T2 + + *のところで終了mailが出てTaskArrayのデータがfreeされてしまうので、よくない + そうならないように、一段TAN(SchedTaskArrayNop)を挟む。 + + write T3 T2 T1 TL TA0 TA1 TA2 TAN% + exec T2 T1 TL TA0 TA1 TA2 TAN T2 + read T1 TL TA TA1 TA2 TAN T2 T3 + next T1 TL TA TA1 TA2 TAN T2 T3 + + %のところで終了mailを送る。T2のreadのところで、TaskArrayのデータはreadbuff上にあるので + 破壊されてしまう。なので、savedTask->task->self の値はTANにコピーして持っていく必要がある 2009-12-19 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - そうか、TaskList->next は、SPE 側で自分で呼び出しているわけね。 - と言うことは、schdule(list) が終るまでは、mail check に戻って - こない... それだと、ちょっとまずいね。 - - となると、TaskList のfree(clear)のtimingは? schdule から抜けた - 時と言うことになるわけだけど。 - - waitQueue は、実は不要。しかし、終了条件、dead lock detection には - 必要らしい。 + そうか、TaskList->next は、SPE 側で自分で呼び出しているわけね。 + と言うことは、schdule(list) が終るまでは、mail check に戻って + こない... それだと、ちょっとまずいね。 + + となると、TaskList のfree(clear)のtimingは? schdule から抜けた + 時と言うことになるわけだけど。 + + waitQueue は、実は不要。しかし、終了条件、dead lock detection には + 必要らしい。 2009-12-16 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - CellTaskManagerのTaskList_bg は変だよ。TaskList 自体が - queue なんだから、トップ二つを特別扱いしているだけでしょう。 - - TaskList をread()しているのと同時にnext()されてしまうので、 - next()の中で、TaskList の中身に触るのは良くない。SchedTask - は微妙に大丈夫らしい。TLのdma waitは、write になっていた。 - - TaskArray/TaskArray1 は、TAの中身をnext()で判断しているので、 - これはただしくない。TaskListLoad を間にはさむ手もあるが... - - write T3 T2 T1 TL TA0 ! TL の dma wait - exec T2 T1 TL! TA0 TA1 - read T1 TL* TA TA1 TA2 * TL の dma start - next T1 TL% TA TA1 TA2 % TAの作成判断 - - TaskListLoad をはさむ、安全だけど遅い方法 - - write T3 T2 T1 TLL TL - exec T2 T1 TLL! TL TA0 - read T1 TLL*TL TA0 TA1 - next T1 TLL TL% TA0 TA1 - - なんだけど、pointer の下位ビットで送ると、前者で実行できる。 - next で、TaskList のloadを始めてしまうという手もあるな... - - write T3 T2 T1 TL TA0 ! TL の dma wait - exec T2 T1 TL TA0 TA1 - read T1 TL! TA TA1 TA2 * TL の dma start - next T1* TL% TA TA1 TA2 - - こっっちかな... + CellTaskManagerのTaskList_bg は変だよ。TaskList 自体が + queue なんだから、トップ二つを特別扱いしているだけでしょう。 + + TaskList をread()しているのと同時にnext()されてしまうので、 + next()の中で、TaskList の中身に触るのは良くない。SchedTask + は微妙に大丈夫らしい。TLのdma waitは、write になっていた。 + + TaskArray/TaskArray1 は、TAの中身をnext()で判断しているので、 + これはただしくない。TaskListLoad を間にはさむ手もあるが... + + write T3 T2 T1 TL TA0 ! TL の dma wait + exec T2 T1 TL! TA0 TA1 + read T1 TL* TA TA1 TA2 * TL の dma start + next T1 TL% TA TA1 TA2 % TAの作成判断 + + TaskListLoad をはさむ、安全だけど遅い方法 + + write T3 T2 T1 TLL TL + exec T2 T1 TLL! TL TA0 + read T1 TLL*TL TA0 TA1 + next T1 TLL TL% TA0 TA1 + + なんだけど、pointer の下位ビットで送ると、前者で実行できる。 + next で、TaskList のloadを始めてしまうという手もあるな... + + write T3 T2 T1 TL TA0 ! TL の dma wait + exec T2 T1 TL TA0 TA1 + read T1 TL! TA TA1 TA2 * TL の dma start + next T1* TL% TA TA1 TA2 + + こっっちかな... 2009-12-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - SimpleTask の実装が出来たので、TaskArray からは、 - PPU側に詳細な情報を返せる。と言うことは、SPU側から - PPU Task を投入出来る。実装すればだけど。 - - Task 側から書き出し情報を設定するAPIが必要。 - マニュアルも書くか。 - - Down cast をすべてなくしたい。Sched*.cc からは取れました。 - - まだ、いらないものが結構あるらしい... + SimpleTask の実装が出来たので、TaskArray からは、 + PPU側に詳細な情報を返せる。と言うことは、SPU側から + PPU Task を投入出来る。実装すればだけど。 + + Task 側から書き出し情報を設定するAPIが必要。 + マニュアルも書くか。 + + Down cast をすべてなくしたい。Sched*.cc からは取れました。 + + まだ、いらないものが結構あるらしい... 2009-12-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - ようやっと動きました。SIMPLE_TASK でないのとの互換性 - を維持するべきか? 頑張れば出来ると思うけど... - - 方法は二つ。TaskList に無理矢理 Task を詰め込むか、 - 今までのHTaskを、TaskArray に読み変えるか。前者は変更が - 多い。後者は、wait_for が微妙。 - - 前者で実装しました。そのうち落すかも。エラーチェックと、 - エラー処理関数が必要。コメントを書かないと。 + ようやっと動きました。SIMPLE_TASK でないのとの互換性 + を維持するべきか? 頑張れば出来ると思うけど... + + 方法は二つ。TaskList に無理矢理 Task を詰め込むか、 + 今までのHTaskを、TaskArray に読み変えるか。前者は変更が + 多い。後者は、wait_for が微妙。 + + 前者で実装しました。そのうち落すかも。エラーチェックと、 + エラー処理関数が必要。コメントを書かないと。 2009-12-12 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - SchedTask::next で、TaskArray を認識して、そこで、 - SchedTaskArrayLoad を作る。次のSchedTask を用意して、 - SchedTaskArrayLoad にsavedSchedTaskとして引き渡す。 - - SchedTaskArrayLoad::read は、TaskArray をload する。 - SchedTaskArrayLoad::next は、SchedTaskArray を返す。 - この時に、saveedSchedTask を引き継ぐ。 - write/exec は何もしない。(これで、pipe line を空ける) - - SchedTaskArray::read は、List DMA をload する。 - SchedTaskArrayLoad::next は、TaskArray 上のTaskを返す。 - exec/write は、List DMA 対応で動作する。 - もうない場合には、SchedTaskArrayLoad から伝えられた - saveされた SchedTask を返す。mail も送る。 + SchedTask::next で、TaskArray を認識して、そこで、 + SchedTaskArrayLoad を作る。次のSchedTask を用意して、 + SchedTaskArrayLoad にsavedSchedTaskとして引き渡す。 + + SchedTaskArrayLoad::read は、TaskArray をload する。 + SchedTaskArrayLoad::next は、SchedTaskArray を返す。 + この時に、saveedSchedTask を引き継ぐ。 + write/exec は何もしない。(これで、pipe line を空ける) + + SchedTaskArray::read は、List DMA をload する。 + SchedTaskArrayLoad::next は、TaskArray 上のTaskを返す。 + exec/write は、List DMA 対応で動作する。 + もうない場合には、SchedTaskArrayLoad から伝えられた + saveされた SchedTask を返す。mail も送る。 2009-12-7 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - pipeline stageは、loop local だから、instance 変数である必 - 要はない。途中で中断することはない。これを一時変数にして、 - 再帰的にpipeline stage を呼び出せば良いらしい。 - - pipeline stage のtask1に引数で new SchedTaskList を渡すと、 - run()でtask1 = new SchedNop() するよりループ二回ぐらい高速 - になるらしい。が、おそらく、ほとんど影響はない。 - - pipelineで既に走っている次のTaskのreadを停める必要があるら - しい。前もってNopを入れて置く方法もあるが、TaskListの境界が - 問題になる。停めないとパイプラインバッファを新たに取る必要 - があり連鎖的にはまる。 - - writeしている奴もいるしな。スケジューラは一段しかネストしな - いから新しくバッファ取るか? いや、やっぱり許されないか。い - や、取るか。うーん、悩ましい。どうせ、Task list は確保しな - いとだめだから… 再帰しないで、もとのスケジューラで動かした - い - - そのためには、既に Pipeline に入っているTaskが邪魔か。２つTask - を投入して、間に TaskList read が入ってもなんとかなるように - 工夫するのが良いっぽい - - なんか、Renew Task の道を歩んでいる気もするが... + pipeline stageは、loop local だから、instance 変数である必 + 要はない。途中で中断することはない。これを一時変数にして、 + 再帰的にpipeline stage を呼び出せば良いらしい。 + + pipeline stage のtask1に引数で new SchedTaskList を渡すと、 + run()でtask1 = new SchedNop() するよりループ二回ぐらい高速 + になるらしい。が、おそらく、ほとんど影響はない。 + + pipelineで既に走っている次のTaskのreadを停める必要があるら + しい。前もってNopを入れて置く方法もあるが、TaskListの境界が + 問題になる。停めないとパイプラインバッファを新たに取る必要 + があり連鎖的にはまる。 + + writeしている奴もいるしな。スケジューラは一段しかネストしな + いから新しくバッファ取るか? いや、やっぱり許されないか。い + や、取るか。うーん、悩ましい。どうせ、Task list は確保しな + いとだめだから… 再帰しないで、もとのスケジューラで動かした + い + + そのためには、既に Pipeline に入っているTaskが邪魔か。２つTask + を投入して、間に TaskList read が入ってもなんとかなるように + 工夫するのが良いっぽい + + なんか、Renew Task の道を歩んでいる気もするが... 2009-12-6 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - やっぱり、Graphical なprofileが欲しいかな。どのDMA/Taskに時間がかかっている - かが見えるようなものが。profile で、メインメモリにlogを書き出すようなもの - が必要。deubg 用のデータ書き出しツールがいるな。 - - log header - command(16) cpu-id(16) event(32) time(64) - struct debug_log { - uint16 command; - uint16 cpu-id; - uint32 event; - uint32 time; - } - ぐらい? get_segment 使うべきか。連続領域に使える get_segement があると - 良いわけね。write とも言うが。 - - sort で、memcpy しているのは変。read/write buffer をflipしてやると - 良い。両方とも握っているんだから問題ない。ただし、read/write buffer - の大きさは等しい必要がある。SchedTask->flip_read_write_buffer(); か? - sort ちゃんとは動いているんだよ。 - - word_count_test の稼働率が10%なのはひどい。word_count の方だと偏りが - あって、一部が50%になるが10%ぐらい。DMA待ちではなくて、メール待ちに - なっている。PPUネックになっているっぽい。 - - TaskArray は、SchedTask を拡張して処理する。next で、次のTaskを - 用意する感じか。inData/outData の処理も。 + やっぱり、Graphical なprofileが欲しいかな。どのDMA/Taskに時間がかかっている + かが見えるようなものが。profile で、メインメモリにlogを書き出すようなもの + が必要。deubg 用のデータ書き出しツールがいるな。 + + log header + command(16) cpu-id(16) event(32) time(64) + struct debug_log { + uint16 command; + uint16 cpu-id; + uint32 event; + uint32 time; + } + ぐらい? get_segment 使うべきか。連続領域に使える get_segement があると + 良いわけね。write とも言うが。 + + sort で、memcpy しているのは変。read/write buffer をflipしてやると + 良い。両方とも握っているんだから問題ない。ただし、read/write buffer + の大きさは等しい必要がある。SchedTask->flip_read_write_buffer(); か? + sort ちゃんとは動いているんだよ。 + + word_count_test の稼働率が10%なのはひどい。word_count の方だと偏りが + あって、一部が50%になるが10%ぐらい。DMA待ちではなくて、メール待ちに + なっている。PPUネックになっているっぽい。 + + TaskArray は、SchedTask を拡張して処理する。next で、次のTaskを + 用意する感じか。inData/outData の処理も。 2009-12-5 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - なんかなぁ。一つの機能を付け加えようとすると、 - - TaskManager/Cell/CellTaskManagerImpl.cc - TaskManager/Cell/CellTaskManagerImpl.h TaskManager/Cell/spe/CellDmaManager.cc - TaskManager/Cell/spe/CellDmaManager.h TaskManager/Cell/spe/ShowTime.cc TaskManager/Cell/spe/ShowTime.h - TaskManager/Cell/spe/SpeTaskManagerImpl.cc TaskManager/Cell/spe/SpeTaskManagerImpl.h - TaskManager/Cell/spe/main.cc TaskManager/Fifo/FifoTaskManagerImpl.cc - TaskManager/Fifo/FifoTaskManagerImpl.h TaskManager/Makefile.cell TaskManager/kernel/ppe/TaskManager.h - TaskManager/kernel/ppe/TaskManagerImpl.h TaskManager/kernel/schedule/DmaManager.h - TaskManager/kernel/schedule/SchedTask.cc TaskManager/kernel/schedule/SchedTask.h - TaskManager/kernel/schedule/Scheduler.h TaskManager/kernel/sys_task/SysTasks.h - example/word_count_test/main.cc - - こんなにファイルをいじらないと出来ない。それって、全然、ダメじゃん。 - - なんでかなぁ。 + なんかなぁ。一つの機能を付け加えようとすると、 + + TaskManager/Cell/CellTaskManagerImpl.cc + TaskManager/Cell/CellTaskManagerImpl.h TaskManager/Cell/spe/CellDmaManager.cc + TaskManager/Cell/spe/CellDmaManager.h TaskManager/Cell/spe/ShowTime.cc TaskManager/Cell/spe/ShowTime.h + TaskManager/Cell/spe/SpeTaskManagerImpl.cc TaskManager/Cell/spe/SpeTaskManagerImpl.h + TaskManager/Cell/spe/main.cc TaskManager/Fifo/FifoTaskManagerImpl.cc + TaskManager/Fifo/FifoTaskManagerImpl.h TaskManager/Makefile.cell TaskManager/kernel/ppe/TaskManager.h + TaskManager/kernel/ppe/TaskManagerImpl.h TaskManager/kernel/schedule/DmaManager.h + TaskManager/kernel/schedule/SchedTask.cc TaskManager/kernel/schedule/SchedTask.h + TaskManager/kernel/schedule/Scheduler.h TaskManager/kernel/sys_task/SysTasks.h + example/word_count_test/main.cc + + こんなにファイルをいじらないと出来ない。それって、全然、ダメじゃん。 + + なんでかなぁ。 SchedTask -> Scheduler -> Connector TaskManagerImpl -> {CellTaskManager,FifoTaskManager/SpeTaskManager} - を全部、いじる羽目になる。 - SchedTask から system call するより、Task を定義して、 - それを呼び出すって方がましかも。 + を全部、いじる羽目になる。 + SchedTask から system call するより、Task を定義して、 + それを呼び出すって方がましかも。 2009-11-23 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - list.bound は廃止。list element から計算可能。 + list.bound は廃止。list element から計算可能。 2009-11-20 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - mail_sendQueue の実装がだめ。こういう実装をすると、queue の - 正しさを関数の中に閉じ込められない。なんか、無限リストにな - っているらしい。参照が、渡り歩いているどこかの場所でダメに - なっているらしい。 - - 実際、mail_sendQueue は、free list に置き換わってしまう。 - これまで、これがおかしくならなかった理由は不明。 - - connector に外から手を入れないで、ちゃんとfunction callするべし。 - - わかりました。 - if (list) { - ... - mainScheduler->send_mailList(in_mail_list); - } - out_mail_list = mainScheduler->recv_mailList(); - - としてしまったが、recv_mailList() でなく、send_mailList で、 - mail_sendQueue をクリアしていたので、 - } else { - mainScheduler->send_mailList(in_mail_list); - } - とする必要があったらしい。if (list) を入れたせいで、こうなった。 - でも、当然、recv_mailList() で clear するべき。atomicity の意味でも。 - なので、send_mailList() での clear は必要ない。 + mail_sendQueue の実装がだめ。こういう実装をすると、queue の + 正しさを関数の中に閉じ込められない。なんか、無限リストにな + っているらしい。参照が、渡り歩いているどこかの場所でダメに + なっているらしい。 + + 実際、mail_sendQueue は、free list に置き換わってしまう。 + これまで、これがおかしくならなかった理由は不明。 + + connector に外から手を入れないで、ちゃんとfunction callするべし。 + + わかりました。 + if (list) { + ... + mainScheduler->send_mailList(in_mail_list); + } + out_mail_list = mainScheduler->recv_mailList(); + + としてしまったが、recv_mailList() でなく、send_mailList で、 + mail_sendQueue をクリアしていたので、 + } else { + mainScheduler->send_mailList(in_mail_list); + } + とする必要があったらしい。if (list) を入れたせいで、こうなった。 + でも、当然、recv_mailList() で clear するべき。atomicity の意味でも。 + なので、send_mailList() での clear は必要ない。 2009-11-19 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - finish_task を全員が待つ設定で、finish_task を終了判定に - 使っている。それだと、すべてのtaskが、finish_task のwait queue - を*必ず*触りにいってしまう。 - - finish_task への待ちを取り除くと、CellTaskManagerImpl::run() - が、 + finish_task を全員が待つ設定で、finish_task を終了判定に + 使っている。それだと、すべてのtaskが、finish_task のwait queue + を*必ず*触りにいってしまう。 + + finish_task への待ちを取り除くと、CellTaskManagerImpl::run() + が、 do { ppeMail = ppeManager->schedule(ppeTaskList); cont: ppeTaskList = mail_check(ppeMail); } while (ppeTaskList); - とかやっているので、ここで抜けてしまう。 - - 要するに、SPUの状態を見て、running がなくなるのを調べるべき - なんだが、SpeTheads は「一つしかない」らしい。spe_running - で、走っているものがあるかどうか見るか? - - Cell だと、MainScheduler と FifoScheduler の二種類の - スケジューラがあるのか。 + とかやっているので、ここで抜けてしまう。 + + 要するに、SPUの状態を見て、running がなくなるのを調べるべき + なんだが、SpeTheads は「一つしかない」らしい。spe_running + で、走っているものがあるかどうか見るか? + + Cell だと、MainScheduler と FifoScheduler の二種類の + スケジューラがあるのか。 MainScheduler --- task list -----> FifoScheduler MainScheduler <-- finish task ---- FifoScheduler - というわけね。 + というわけね。 2009-11-15 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - List DMAって、32bit address を使っているらしい。それは、ちょっと - ひどいなぁ。 + List DMAって、32bit address を使っているらしい。それは、ちょっと + ひどいなぁ。 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - やっぱり、TaskList の存在が許せない。あったとしても不定長でしょう。 - 無駄なコピーが多すぎる。 + やっぱり、TaskList の存在が許せない。あったとしても不定長でしょう。 + 無駄なコピーが多すぎる。 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - Scheduler / TaskManger / TaskManagerImpl の区別が不明 - HTask は、TaskManagerImpl を持ってる。 - - Scheduler は SchedTask から直接見えないはずだが、SchedTask は、 - Scheduler は知っているが、TaskManager は知らない。これがかなりの - 混乱を生んでいる。 - - SPU上では、TaskManager が存在しないのが原因らしいが、allcoate とかは、 - TaskManager が行うはず。なので、SPU上にもTaskManagerがある方が自然。 - - SchedTask が自分自身で scheduling してしまっているので、Scheduler - には、ほとんど仕事がない。なので、大半の処理を scheduler -> manager - 経由で行うことになる。 + Scheduler / TaskManger / TaskManagerImpl の区別が不明 + HTask は、TaskManagerImpl を持ってる。 + + Scheduler は SchedTask から直接見えないはずだが、SchedTask は、 + Scheduler は知っているが、TaskManager は知らない。これがかなりの + 混乱を生んでいる。 + + SPU上では、TaskManager が存在しないのが原因らしいが、allcoate とかは、 + TaskManager が行うはず。なので、SPU上にもTaskManagerがある方が自然。 + + SchedTask が自分自身で scheduling してしまっているので、Scheduler + には、ほとんど仕事がない。なので、大半の処理を scheduler -> manager + 経由で行うことになる。 2009-11-14 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - 要するに、SPE task 側から addOutData できればよい。 - でも、別に、PPE側から計算してもよいはずだけどね。 - そうすれば、renew task は取り外せる。 + 要するに、SPE task 側から addOutData できればよい。 + でも、別に、PPE側から計算してもよいはずだけどね。 + そうすれば、renew task は取り外せる。 SchedDefineTask1(DrawSpanEnd,draw_span_end); - で、名前を指定させておいて、さらに、 - SchedExternTask(DrawSpanEnd); - SchedRegisterTask(TASK_DRAW_SPAN_END, DrawSpanEnd); - で、新しく名前を要求するのって、なんとかならんの? 読みづらいんだよ。 - DrawSpanEnd を、そのまま使ってもよさそうだけど? - - せっかく、renew task を外したのに、HD crash で失ってしまいました。 - - add_param が順序を持っているのは見づらい。数字で指定する方が合理的。 + で、名前を指定させておいて、さらに、 + SchedExternTask(DrawSpanEnd); + SchedRegisterTask(TASK_DRAW_SPAN_END, DrawSpanEnd); + で、新しく名前を要求するのって、なんとかならんの? 読みづらいんだよ。 + DrawSpanEnd を、そのまま使ってもよさそうだけど? + + せっかく、renew task を外したのに、HD crash で失ってしまいました。 + + add_param が順序を持っているのは見づらい。数字で指定する方が合理的。 2009-10-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - 単純な、rbuf, wbuf + write return size の task のAPI - List DMA の API - 投入 cpu 別の spawn method - Redering 時の内部からの DMA への直接アクセスへの禁止等など - - set_post で登録する関数も、task のrun関数と同じ型にした方が便利そう。 - - SPU側でも配列(TaskList)ではなく、TaskQueue で管理すれば、 - renew task は簡単に実装できる。 - - SchedTask の renew かそうでないかの区別は全部なくす。ex_init とかは、 - なくなるはず。その代わり TaskQueue で管理する。 - - TaskList に inListData/outListData が入っているのは、やはりおかしい。 - もっとコンパクトであるべき。 - - TaskList は、こまめに終了をPPE側へ知らせるのではなく、TaskListの - 書き換えで知らせる方が良い。 - - SPUからPPUへ、create task 出来た方が良い。それはTaskList の書き出し - で行なう。 + 単純な、rbuf, wbuf + write return size の task のAPI + List DMA の API + 投入 cpu 別の spawn method + Redering 時の内部からの DMA への直接アクセスへの禁止等など + + set_post で登録する関数も、task のrun関数と同じ型にした方が便利そう。 + + SPU側でも配列(TaskList)ではなく、TaskQueue で管理すれば、 + renew task は簡単に実装できる。 + + SchedTask の renew かそうでないかの区別は全部なくす。ex_init とかは、 + なくなるはず。その代わり TaskQueue で管理する。 + + TaskList に inListData/outListData が入っているのは、やはりおかしい。 + もっとコンパクトであるべき。 + + TaskList は、こまめに終了をPPE側へ知らせるのではなく、TaskListの + 書き換えで知らせる方が良い。 + + SPUからPPUへ、create task 出来た方が良い。それはTaskList の書き出し + で行なう。 2009-10-11 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - ようやっと直せました。inListData/outListData は別に転送しないで、 - 一緒に転送してしまった方が良い。どうせ、いつも転送しているのだから。 - - word_count が fifo の方が高速なのは、どうにかしてください。 - - Renew Task の addInData は、メインメモリからDMAするので正しいらしい。 - 直し方を間違えた。 - - Task をmemcpyして、TaskList に入れているが、List DMA に直すべき。 - Simple Task を常に起動して、List DMA task は、その中で、Renew Task - として起動するのが良いのでは? そうすれば、Task Load 自体を Task に - 出来る。 - - Renew Task の実行順序が filo になっている。このあたり変なので、 - 修正するべきでしょう。Renew用の TaskList を持てば良いんじゃないか? - task->self の ad-hoc な使い方が泣ける。ひどすぎます。 + ようやっと直せました。inListData/outListData は別に転送しないで、 + 一緒に転送してしまった方が良い。どうせ、いつも転送しているのだから。 + + word_count が fifo の方が高速なのは、どうにかしてください。 + + Renew Task の addInData は、メインメモリからDMAするので正しいらしい。 + 直し方を間違えた。 + + Task をmemcpyして、TaskList に入れているが、List DMA に直すべき。 + Simple Task を常に起動して、List DMA task は、その中で、Renew Task + として起動するのが良いのでは? そうすれば、Task Load 自体を Task に + 出来る。 + + Renew Task の実行順序が filo になっている。このあたり変なので、 + 修正するべきでしょう。Renew用の TaskList を持てば良いんじゃないか? + task->self の ad-hoc な使い方が泣ける。ひどすぎます。 2009-10-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - Task 内の create_task は、SchedTask に対してで、 - PPE 上では、Manager に対してだよね。だから、出来る - ことがかなり異なる。これは、まずいだろ? - - 特に、PPE task に明示的に manager を渡すってのは、 - とっても変。 - - Renew Task の特別扱いが、いろいろ歪めているんだが、 - view.cc で使っているので落せない。 + Task 内の create_task は、SchedTask に対してで、 + PPE 上では、Manager に対してだよね。だから、出来る + ことがかなり異なる。これは、まずいだろ? + + 特に、PPE task に明示的に manager を渡すってのは、 + とっても変。 + + Renew Task の特別扱いが、いろいろ歪めているんだが、 + view.cc で使っているので落せない。 2009-10-05 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - TaskQueue のfree list の管理はシステムで一つであるべき。 - TaskQueue は double linked list が当然らしい。 + TaskQueue のfree list の管理はシステムで一つであるべき。 + TaskQueue は double linked list が当然らしい。 2009-10-02 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - DrawSpan で、~DrawSpan() で、allocate したデータを DMA_WAIT - して、free しているが、これは、抽象化違反。Task で明示的に - DMAするのは禁止。Task 内で、add_outData 出来れば良い。 - - renew が正しいような気がするが... - - Task 内で大域変数は使えない。なので、smanager からallocateする - 必要がある。Task の解放のタイミングではなくて、パイプラインの - タイミングでDMA waitとfreeを行なう必要がある。DrawSpan の場合は、 - add_outData で良いが、内部で allocate/free は行なう必要がある。 - put_segement がパイプライン動作するべきなのか? - - 固定のDMA tagが邪魔。 - - DrawSpan は全般的にダメだな〜 - - でも、その変更は大きいので、とりあえず動くようにしたい。 - - memset 0 は、7.7.3 SL1 Data Cache Range Set to Zero コマンド - つかうべき。SPE側でやっても良い。でも、本来は全面埋まるのが - 普通なのでどうでも良いけど。 + DrawSpan で、~DrawSpan() で、allocate したデータを DMA_WAIT + して、free しているが、これは、抽象化違反。Task で明示的に + DMAするのは禁止。Task 内で、add_outData 出来れば良い。 + + renew が正しいような気がするが... + + Task 内で大域変数は使えない。なので、smanager からallocateする + 必要がある。Task の解放のタイミングではなくて、パイプラインの + タイミングでDMA waitとfreeを行なう必要がある。DrawSpan の場合は、 + add_outData で良いが、内部で allocate/free は行なう必要がある。 + put_segement がパイプライン動作するべきなのか? + + 固定のDMA tagが邪魔。 + + DrawSpan は全般的にダメだな〜 + + でも、その変更は大きいので、とりあえず動くようにしたい。 + + memset 0 は、7.7.3 SL1 Data Cache Range Set to Zero コマンド + つかうべき。SPE側でやっても良い。でも、本来は全面埋まるのが + 普通なのでどうでも良いけど。 2009-08-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - で、MemList/MemHash が TaskManager 側に移ったので、 - これで、code の management を書くことが出来る。 - そうすれば、SPEのメモリの限界をほんと気にする必要がなくなるはず。 - - その前に、get_segment の例題を直さないと。 - - DrawSpanRnew/reboot は使ってないらしい。 - - Tree は、配列にしないでlinkをSPE側からたどるようになっている。 - それは良いのだが、Task 側で dma_wait するような実装は望ましくない。 - この部分も書き直す必要がある。list 構造の SPE上の Iterator を - 実装すれば良い。 - - memory 関係のコードが scheduler の下にあるのは面白くない。 - - Scheduler で実装(__scheduler)に移譲している部分は、headerに - 移した方が良い。 + で、MemList/MemHash が TaskManager 側に移ったので、 + これで、code の management を書くことが出来る。 + そうすれば、SPEのメモリの限界をほんと気にする必要がなくなるはず。 + + その前に、get_segment の例題を直さないと。 + + DrawSpanRnew/reboot は使ってないらしい。 + + Tree は、配列にしないでlinkをSPE側からたどるようになっている。 + それは良いのだが、Task 側で dma_wait するような実装は望ましくない。 + この部分も書き直す必要がある。list 構造の SPE上の Iterator を + 実装すれば良い。 + + memory 関係のコードが scheduler の下にあるのは面白くない。 + + Scheduler で実装(__scheduler)に移譲している部分は、headerに + 移した方が良い。 2009-08-06 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - うーん、get_segemnt で、dma_wait のtagをなんとかする - 必要があるらしい。get_tag() でなんとかなるけど、 - 他のtag との関係があるかな。 - - 完全に見えなくするべきでしょうけど... 今はいい。 + うーん、get_segemnt で、dma_wait のtagをなんとかする + 必要があるらしい。get_tag() でなんとかなるけど、 + 他のtag との関係があるかな。 + + 完全に見えなくするべきでしょうけど... 今はいい。 2009-08-01 Shinji KONO <kono@ie.u-ryukyu.ac.jp> - MemList は動いたので、今度は TileHash を TaskManager 側に移動する - 必要がある。 - - その後、コードのLRUを書けば、Cerium は一通り出来上がり。 - - TaskManager と Scheduler の関係が一貫してない。複雑すぎる。 + MemList は動いたので、今度は TileHash を TaskManager 側に移動する + 必要がある。 + + その後、コードのLRUを書けば、Cerium は一通り出来上がり。 + + TaskManager と Scheduler の関係が一貫してない。複雑すぎる。 2009-07-24 Kaito TAGANO <tkaito@cr.ie.u-ryukyu.ac.jp> @@ -547,7 +589,7 @@ } class MemList { - MemorySegment* first; + MemorySegment* first; MemorySegment* last; MemList* createMemList(uint32 size, uint32 count); @@ -983,7 +1025,7 @@ --- 記述例 --- printf("the number of available entries = %d\n", - spe_in_mbox_status(spe_ctx)); + spe_in_mbox_status(spe_ctx)); --- 実行結果 --- the number of available entries = 4 @@ -1059,13 +1101,13 @@ 使っているので、SchedTask にそって実行する場合、 __scheduler->dma_load(__inListData, (uint32)__task->inData, - sizeof(ListData), DMA_READ_IN_LIST); + sizeof(ListData), DMA_READ_IN_LIST); __scheduler->dma_load(__outListData, (uint32)__task->outData, - sizeof(ListData), DMA_READ_OUT_LIST); + sizeof(ListData), DMA_READ_OUT_LIST); の代わりに - memcpy(__inListData, __task->inData, sizeof(ListData)); + memcpy(__inListData, __task->inData, sizeof(ListData)); memcpy(__outListData, __task->outData, sizeof(ListData)); free(__task->inData); free(__task->outData); @@ -1088,8 +1130,8 @@ test_cpy(int flag, int *src) { if (flag) { - memcpy(data, src, sizeof(int)*length); - free(src); + memcpy(data, src, sizeof(int)*length); + free(src); } } @@ -1100,13 +1142,13 @@ test_nocpy(int flag, int *src) { if (flag) { - data = src; + data = src; } // この部分を SchedTask::~SchedTask() と // 思ってください if (flag) { - free(data); + free(data); } } @@ -1116,7 +1158,7 @@ flag は 1 or 0 の繰り返しです。 - 実行結果 (1) - :no copy + :no copy SPE time by SPU Decrementer: 0.035500 :copy SPE time by SPU Decrementer: 0.057500 @@ -1141,7 +1183,7 @@ test_nocpy(int flag, int *src) { if (flag) { - data = src; + data = src; } free((void*)(flag*(int)data)); @@ -1213,11 +1255,11 @@ free((TaskListPtr)(__flag_renewTask*(int)(__list))); #else if (__flag_renewTask) { - free(__inListData); - free(__outListData); - free(__list); + free(__inListData); + free(__outListData); + free(__list); } - #endif + #endif こんな感じで、いくつかか if 文を消してみた。 そして、PPE側の main.cc で gettimeofday で計測してみた (各10回) @@ -1332,7 +1374,7 @@ free((void*)(flag_renewTask*(int)(list))); #else if (flag_renewTask) { - free(list); + free(list); } #endif @@ -1611,7 +1653,7 @@ * add (API): set_post - create_task(id, 0); + create_task(id, 0); とかわざわざ 0 付けるのもアレなので、もうそれように @@ -1838,9 +1880,9 @@ 今までは if (spe_out_mbox_read(spe_ctx[speid], &ret, 1) < 0) { - return ret; + return ret; else - return -1; + return -1; とやっていた。これは @@ -1996,7 +2038,7 @@ セマフォの P 動作は、基本的に --------------------- - pthread_mutex_lock(&sem->mutex); + pthread_mutex_lock(&sem->mutex); while(sem->value == 0) { // 資源が無い // 条件付き変数に自分を登録して、ロックを解放して、他の @@ -2166,7 +2208,7 @@ 必要がある。その計算をミスってました。 1 ////////// - <- なぜか書き込まれていない + <- なぜか書き込まれていない ////////// //////////