# HG changeset patch
# User Masataka Kohagura <e085726@ie.u-ryukyu.ac.jp>
# Date 1392385192 -32400
# Node ID 7db708d208d1537908ea065ccee501d469fb7f53
# Parent  a2a0903b5619f7ddeac0697cbb6c5a11b365ff5f
add 14th.txt

diff -r a2a0903b5619 -r 7db708d208d1 2014/February/memo/12th.txt
--- a/2014/February/memo/12th.txt	Fri Feb 14 14:18:52 2014 +0900
+++ b/2014/February/memo/12th.txt	Fri Feb 14 22:39:52 2014 +0900
@@ -10,4 +10,11 @@
             -> mmap だと、Taskで読み込む範囲のreadしか行われない。 Task の数だけ read が発生する
             -> Broked Read だと、複数Task 分だけ読み込むので、read の発生回数がmmap時よりすくなくなる。(要検証)
     ・実メモリに読み込むとき、 swap が起こるかどうか。
-            
+
+    ・ やはりどのぐらい改善されたかという数値を出すときには、パーセンテージのほうがよい。
+    ・ IO_0 という CPU Type を追加したという話をした後の実験結果の見せ方が悪すぎた。
+        4 CPU と 12 CPU で比較していたが、IO_0 を 4 CPU 準備したと思われてもおかしくない。
+    ・  もっとくわしく書くべきだった。
+        mmap は 4 CPU (IO と Task が分離できないため) でいいが
+        Broked Read は IO 専用 CPU 1 + Task CPU 3
+        のように詳しく記述する必要があった。
diff -r a2a0903b5619 -r 7db708d208d1 2014/February/memo/14th.txt
--- a/2014/February/memo/14th.txt	Fri Feb 14 14:18:52 2014 +0900
+++ b/2014/February/memo/14th.txt	Fri Feb 14 22:39:52 2014 +0900
@@ -1,13 +1,23 @@
-2014/02/12 (Wed)
+2014/02/14 (Fri)
 
     [memo]
-    院試での卒論発表
-    質問された内容
-    ・Broked Read 実装のメリット
-    ・IO 専用の thread を準備しているが、 priority を自分自身であげることができるのか
-    ・IO 専用 thread でどれだけ速くなったのか。 ->10秒ほどはやくなった。
-    ・IO ネックになっているが、mmap と read 両方共結局同じ結果になりそうだが
-            -> mmap だと、Taskで読み込む範囲のreadしか行われない。 Task の数だけ read が発生する
-            -> Broked Read だと、複数Task 分だけ読み込むので、read の発生回数がmmap時よりすくなくなる。(要検証)
-    ・実メモリに読み込むとき、 swap が起こるかどうか。
-            
+        mmap は仮想アドレスを取得する。
+        ヒープ領域を伸ばせなくても、別の空き領域を自動的に取得してそこにメモリを確保する。
+            -> しかし、連続じゃないということは、その領域を探すという段階にオーバーヘッドがでるのでは
+
+        mmap は kernel の機能を利用するため、OS依存になる。
+        (OS によって kernel がかわるため)
+
+        *要検証
+        Linux の malloc は
+            128KB未満のメモリー要求に対してはヒープから割り当てる。(brk() でとってるらしい)
+            128KB以上のメモリー要求に対してはmmapを使用する。
+        らしい
+            -> あれ??つまり malloc は物理メモリアドレスを連続で確保しているわけではないので、遅くならね??
+                -> 連続で格納されていなくても、断片的にすでに読み込まれているから早いのか??
+                    -> read 関数よりも、malloc の調整次第でもっと速くなるのでは
+
+
+
+    [卒論]
+        いままでしてきた過程をすべて書くことによって説得力が徐々に湧いていくよね
diff -r a2a0903b5619 -r 7db708d208d1 2014/OUTLINE
--- a/2014/OUTLINE	Fri Feb 14 14:18:52 2014 +0900
+++ b/2014/OUTLINE	Fri Feb 14 22:39:52 2014 +0900
@@ -3,11 +3,14 @@
     論文 : それぞれの chapter の OUTLINE を書き上げる
 
     [memo]
+    mmap malloc について調べてみた
 
 2014/02/12 (Wed)
     [memo]
     院試発表反省会
 
+---------------------------------------------------------------------------
+
 2014/02/08 (Sun)
     [images]
     blockread.png --> final/slide/images