# HG changeset patch
# User Masataka Kohagura <e085726@ie.u-ryukyu.ac.jp>
# Date 1392386463 -32400
# Node ID ce985cabf6992d32f4efb240e03c671749229dba
# Parent  03c8790e34b5c694df1939350b5033cd6e53e4a4
add OUTLINE chapter4

diff -r 03c8790e34b5 -r ce985cabf699 paper/chapter3.tex
--- a/paper/chapter3.tex	Fri Feb 14 17:03:34 2014 +0900
+++ b/paper/chapter3.tex	Fri Feb 14 23:01:03 2014 +0900
@@ -3,23 +3,46 @@
 
 \section{File Read}
 ・ ファイルを分割して読み込むプログラム
+
 ・ Task Manager 側でメモリを確保して、Task 側で読み込んだファイルをそのメモリに格納していく。
+
 ・ C の ファイル読み込みの API である pread を使用する。
-・ <image>(File Read の図でもいれようかしら)
+
+・ [image](File Read の図でもいれようかしら)
+
 ・ 実験結果の載っける
+
 ・ 分割を少なくしたほうが、pread (System call)が呼ばれる回数がすくなくなるので無駄がすくなくなる。
 
+
 \section{Boyer-Moore String Search Algorithm}
+
+・ IO を含む Task なので、ここで説明
+
+・ [image]IO を含む Task の図
+
 ・ BM Search の概要
+
     BM Search は XXX が XXX 年に発表した文字列探索アルゴリズム
+
     ほかにもいろいろ
-    <image>BM Search の skip table の説明と図
-    <image>BM Search の実行時の説明と図
+
+    [image]BM Search の skip table の説明と図
+
+    [image]BM Search の実行時の説明と図
+
 ・ BM Search をテキストにかけて、検索文字列が含まれてい数をカウントする。
-・ <image>ファイルを一括で BM Search かけるのではなく、あるサイズに分割してから計算し、
+
+・ [image]ファイルを一括で BM Search かけるのではなく、あるサイズに分割してから計算し、
+
     その結果を print で集計する様子を追加
-・ <image>分割で読み込むときに分割サイズを間違えると正しい結果が返ってこない。
+
+・ [image]分割で読み込むときに分割サイズを間違えると正しい結果が返ってこない。
+
 ・ 実験結果を載っけたい
+
     実験結果どうしよう
+
     文字列検索して数を数えるプログラムだが、それに対応する Mac のコマンドが、grep -c [検索文字列]
+
     比較対象をどうしようかしら
diff -r 03c8790e34b5 -r ce985cabf699 paper/chapter4.tex
--- a/paper/chapter4.tex	Fri Feb 14 17:03:34 2014 +0900
+++ b/paper/chapter4.tex	Fri Feb 14 23:01:03 2014 +0900
@@ -2,9 +2,72 @@
 \label{chap:poordirection}
 
 \section{mmap}
+・mmap の仕様
 
-\section{map reduce}
+    mmap の細かい話をここで書く
+
+    [image]mmap の読み込むときの図をここに
+
+・ mmap は kernel 部分の実装によるものなので、OS によってかわってしまう。
+
+・ mmap が呼び出されているときにファイルを読み込むわけではない。仮想メモリに格納されているだけ。
+
+・ mmap された領域に対してアクセスされたときに初めて実メモリに呼び出される。
+
+・ OS によってうごきが変わってしまうので、自分自身で制御できない
+
+・ 並列処理でファイル読み込みを行う Task を扱うと、1つ1つの Task が[読み込む → Task が走る]
+
+・ I/O 読み込みはネックになるが、そのネックが Task 1つ1つにふりかかる。
+
+・ I/O と Task を完全に分けたほうがいいのでは。と考えた。
+
+\section{pread}
+(これ書かなくてもいい説?)
+
+・ I/O を mmap ではなく、pread 関数で実装した
+
+・ pread の概要
+
+・ pread で実装すると、自分自身で制御できる。
+
+・ TaskManager で allocate して、Task として呼び出した pread で allocate 部分に格納している
+
+・ 格納してから Task が走っているので、まだ並列には走っていない(IO後、Task が走るようになっている)
+
+・ [image]その時の状況でも図にする??
 
-\section{I/O の設計}
-\section{I/O の実装}
+・ その時の実行速度も??
+
+\section{Broked Read の設計と実装}
+・ pread で実装したものを、Task と IO が並列に動くようにしないといけない
+
+・ pread は常に走っていているのが理想
+
+
+・ [image]そのimage をここに貼る
+
+・ Task は実際には 1個1個生成しているのではなく
+
+・ これで IO と Task が同時にはしるようになった
+
+・ 実験結果??
+
+・ Cerium の Task に CPU Type を設定することができる。しかし、同じCPU Type を使用すると、IO を担当している CPU に Task が割り振られて、read 全体の速度が遅くなってしまう。
+
+・ [image] priority を上げる前の image 図
+
 \section{Cerium の改良}
+・ Cerium では ptherad で並列処理を記述している
+
+・ SPY\_ANY という CPU Type は、Cerium 側が自動的に CPU 割り当てを行う便利なマクロ
+
+・ SPE\_ANY を使用すると、IO の部分にも割り込まれてしまうので、これをどうにかしたい。
+
+・ IO\_0 という新しい CPU Type を追加
+
+・ pthread の API で CPU の priority をあげることができる。
+
+・ [image] priority を上げたときの image 図
+
+・ これで IO 部分に割り込みがおこらないよね!!
diff -r 03c8790e34b5 -r ce985cabf699 paper/thesis-paper.pdf
Binary file paper/thesis-paper.pdf has changed