--- 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 の調整次第でもっと速くなるのでは
+
+
+
+    [卒論]
+        いままでしてきた過程をすべて書くことによって説得力が徐々に湧いていくよね