Mercurial > hg > Members > yuuhi > slide

comparison s6/blank.html @ 7:fb400fcfbb3a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
malloc
author Yuhi TOMARI <yuhi@cr.ie.u-ryukyu.ac.jp>
date Tue, 21 Oct 2014 15:52:21 +0900
parents 220243d8ef68
children 005ab4fdd25d
comparison
equal deleted inserted replaced
6:8b6d326c1402 7:fb400fcfbb3a
1 \<!DOCTYPE html> 1 <!DOCTYPE html>
2 <html> 2 <html>
3 <head> 3 <head>
4 <meta charset='utf-8'> 4 <meta charset='utf-8'>
5 <title>Seminar</title> 5 <title>Seminar</title>
6 6
86 86
87 <div class='slide cover'> 87 <div class='slide cover'>
88 <table width="90%" height="90%" border="0" align="center"> 88 <table width="90%" height="90%" border="0" align="center">
89 <tr> 89 <tr>
90 <td><div align="center"> 90 <td><div align="center">
91 <h1><font color="#808db5">Ceriumの再設計</font></h1> 91 <h1><font color="#808db5">CeriumにおけるGPGPUの最適化</font></h1>
92 </div></td> 92 </div></td>
93 </tr> 93 </tr>
94 <tr> 94 <tr>
95 <td><div align="left"> 95 <td><div align="left">
96 Yuhi TOMARI 96 Yuhi TOMARI
112 </table> 112 </table>
113 </div> 113 </div>
114 114
115 <div class='slide'> 115 <div class='slide'>
116 <h2>研究目的</h2> 116 <h2>研究目的</h2>
117 <ul> 117 <p>
118 <li>当研究室ではCS/DSを使用したプログラミングを行っている</li> 118 当研究室ではCellおよびLinux、
119 <dd>CS/DSについて</dd> 119 Mac OSX上で動く並列プログラミングフレームワーク、
120 <li>CS/DSベースのフレームワーク(?)の開発</li> 120 Ceriumの開発・改良を行っている。
121 <dd>もっと大きい何かなのでは……？</dd> 121 </p>
122 <li>独自のMemory Managementの機構を持つ</li> 122 <p>本研究では新たにGPU上での並列実行に対応し、
123 <li>Cerium・Alice・jungleで得られた知見を……</li> 123 ヘテロジニアス(異種混合)環境下でのプログラミングをサポートする
124 <li>なぜ新しく設計し直す必要がある？</li> 124 </p>
125 <li>名前も考える必要がある？</li> 125 <p>
126 </ul> 126 GPGPUでは通常のマルチコア<font color="red">CPUとは異なる並列プログラミング</font>
127 </div> 127 と<font color="red">特別なチューニング</font>が必要となる。
128 128 そこでCeriumを用いてその差を吸収し、自動的なチューニングを可能にする。
129 <div class='slide'> 129 </p>
130 <h2>Code/Data Segment Systemの構造</h2> 130 <p>
131 <img src="images/new_cerium.png" width="800"> 131 しかし、GPUのみで並列計算を行った場合、Taskによっては並列度が出ない場合がある。
132 <p>全てはDSとして扱われる。CSもDSの一種。</p> 132 そこでチューニングの一環として、MultiCoreとGPU上での同時実行を可能にする。
133 <p>TaskもDSで、CSとDSの組になっている。</p> 133 </p>
134 </div> 134 </div>
135 135
136 <div class='slide'> 136 <!-- h1.hidden => use heading just for table of contents (toc) -->
137 <h2>Temporary/Persistent Space</h2> 137 <div class='slide'>
138 <h2>進捗</h2>
139 <dl>
140 <dt>Scalaで遊んでた</dt>
141 <dt>mallocのお勉強</dt>
142 <dd>kernel reading party(小崎さん)</dd>
143 <dd><a href="http://shelby.tv/video/youtube/0-vWT-t0UHg/the-67th-yokohama-kernel-reading-party">動画</a></dd>
144 <dd><a href="http://www.slideshare.net/kosaki55tea/glibc-malloc">資料</a></dd>
145 </div>
146
147 <div class='slide'>
148 <h2>mallocってなんだっけ……？</h2>
149 <pre class="code">
150 void *malloc(size_t size);</pre>
151 <img src="images/malloc.png" width="500">
152 <ul>
153 <li>mallocはsizeバイト分のメモリを割り当て、ポインタを返す</li>
154 <li>返ってくるのはvoidのポインタなので、戻り値を型でキャストする必要がある</li>
155 <li>中身は初期化されていない</li>
156 <li>確保した領域はfreeを忘れずに</li>
157 </ul>
158 <pre class="code">
159 char *str = (char*)malloc(length); // 使う型でキャストする</pre>
160 </div>
161
162 <div class='slide'>
163 <h2>古典的malloc(K&R malloc)</h2>
164 <img src="images/heap.png" width="700">
165 <ul>
166 <li>使用可能なブロックを繋げたリスト構造、free list (freeされているブロックのlist?)
167 <li>listを使ってメモリを管理
168 <li>管理領域(header)分だけ多くallocateして、先頭に管理領域を付加
169 <li>first fit
170 </ul>
171 <hr>
172 <pre class="code">
173 union header {
174 struct {
175 union header *ptr; // 空きリストの上なら次のブロック
176 unsigned size; // このブロックの大きさ
177 } s;
178 };</pre>
179 </div>
180
181 <div class='slide'>
182 <h2>First Fit</h2>
183 <p>
184 リストを頭から見ていって、最初に見つけたものを使用するというすごいシンプルな方法。
185 </p>
186 <img src="images/firstfit.png" width="500">
187 </div>
188
189 <div class='slide'>
190 <h2>First Fit</h2>
191 <img src="images/firstfit2.png" width="500">
192 <p>実は、もう一個先にもっと適切なブロックがあった。こんな場合に対応できない…というか、対応しないのがfirst fit。</p>
193 <p>あまりよくない……</p>
194 </div>
195
196 <div class='slide'>
197 <h2>free</h2>
198 <pre class="code">
199 void free(void *ptr);</pre>
200 <p>
201 メモリの開放自体は、使用中のブロックをfree listに追加するだけで良い。
202 引数で受け取ったポインタ部分を開放したら良い……かに思える。
203 でもそれだけじゃダメで、開放したい領域と隣接しているブロックが空きブロックなら併合しないといけない。
204 </p>
205 <img src="images/free_merge.png" width="700">
206 </div>
207
208 <div class='slide'>
209 <h2>free</h2>
210 <img src="images/free1.png" width="700">
211 <p>
212 listから最初のポインタと、その次のポインタを取得。prev < p < nextを満たすまで走査していく
213 </p>
214 </div>
215
216 <div class='slide'>
217 <h2>free</h2>
218 <img src="images/free2.png" width="700">
219 <p>あった！！</p>
220 <p>
221 開放後に前後のメモリと併合する必要がある場合があるので、prevとp・pとnextが隣接してるか判定する。
222 </p>
223 <ul>
224 <li>(prev+prev-&gt size) != p なので、隣接していない </li>
225 <li>(p+p-&gt size) = next なので、隣接している</li>
226 <p>ブロックが隣接している場合は併合する。</p>
227 </div>
228
229 <div class='slide'>
230 <h2>free</h2>
231 <img src="images/free_after.png" width="700">
232 <p>チェックに引っかかったところをマージする。</p>
233 </div>
234
235 <div class='slide'>
236 <h2>古典的malloc & freeまとめ</h2>
237 <p>フラグメンテーションが頻発する。</p>
238 <ul>
239 <li>このmallocが主流だった時は「メモリはプログラムの最初に一気に確保するもの」だった</li>
240 <li>メモリが充分に空いている状態で、
241 必要なメモリを一気に確保するならフラグメンテーションは起きにくい</li>
242 <li>今はJava・C++のようなオブジェクト指向言語、
243 Rubyのようなスクリプト言語等、小さいmallocが頻発するものが多い</li>
244 <li>それをfirst fitでやるのはよくない</li>
245 </ul>
246
247 </div>
248
249
250 <div class='slide'>
251 <h2>mallocの改良</h2>
252 <p>そもそも、一つのfree listで管理することが無理がある</p>
253 <p>サイズ16Byte用のリスト、サイズ24Byte用のリスト……というようにリストを複数作ってやる</p>
254 <table border="0">
255 <tr>
256 <th>
257 <img src="images/free_list_list.png" width="400">
258 </th>
259 <th valign="top" align="left">
260 <ul>
261 <li>mallocで要求されたsizeを8で割れば自分が使用するindexとなる</li>
262 <li>無限にリストを増やすわけにはいかないので、このリストを使うのは512バイト以下の場合のみ</li>
263 <li>512バイト以上の大きいデータの場合は、特殊な管理を行う</li>
264 <li>大きいデータと小さいデータを一緒に管理するからフラグメンテーションが進むんだ<br>
265 →大きいデータ用の領域がもう一個欲しい<br>→そうだ、mmapを使おう</li>
266 </th>
267 </tr>
268 </table>
269 </div>
270
271
272 <div class='slide'>
273 <h2>mmapってなんだっけ……？</h2>
274 <ul>
275 <li>ファイル(fdで指定したもの)をメモリにマップする</li>
276 <li>fdで&quot;/dev/zero&quot;を指定することでmmapをメモリ確保APIとして使用</li>
277 <li>このAPIを使ってHuge Blockはmmapで直接kernelから取得する</li>
278 </ul>
279 <pre class="code">
280 void *alloc_mmap(size_t size) {
281 int fd = open("/dev/zero", O_RDONLY);
282 void *ret = mmap(addr, length, prot, flags, fd, offset);
283 return ret;
284 }</pre>
285 <table border="1" >
286 <tr bgcolor="dbffa3">
287 <th align="left" style="margin:10px 10px 10px;">addr</th><th align="left">mapするメモリアドレス。NULLを渡せばkernelがアドレスを選択する。</th>
288 </tr>
289
290 <tr bgcolor="palegreen">
291 <th align="left">length</th><th align="left">addrから何バイトマッピングするか。</th>
292 </tr>
293
294 <tr bgcolor="dbffa3">
295 <th align="left" >prot</th><th align="left">マッピングのメモリ保護の指定。Read Write Exec None等がある。</th>
296 </tr>
297 <tr bgcolor="palegreen">
298 <th align="left">flags</th><th align="left">マップを要求された時、共有するかコピーを渡すか。</th>
299 </tr>
300 <tr bgcolor="dbffa3">
301 <th align="left">offset</th><th align="left">ファイルの何バイト目からをメモリにマップするか。</th>
302 </tr>
303 </table>
304 </div>
305
306 <div class='slide'>
307 <h2>Huge Block</h2>
308 <p>mmapで確保するので、free listからは独立している。
138 <table> 309 <table>
139 <tr> 310 <tr>
140 <th><img src="images/ts_ps.png" width="400"></th>
141 <th> 311 <th>
142 <dl align="left"> 312 <img src="images/huge_block.png" width="500">
143 <dl align="left">
144 <dt>Temporary Space, Persistent Space</dt>
145 <dd><li>DSはTemporary SpaceかPersistent Spaceに属する</dd>
146 <dd><li>Temporary Spaceはポインタでアクセス。</li>
147 <li>Persistent SpaceはURLでアクセス。つまり、名前を持つ。<br>
148 (Persistent Space に書き込む = DBに登録する)</dd>
149 </dl>
150 </dl>
151 </th> 313 </th>
152 </tr> 314 <th valign="top" align="left">
153 </table> 315 <p>
154 <dt>Task</dt> 316 listを使って管理しているわけではないので、listをたどったりしなくて良い。</p>
155 <dd><li>Input DS, Output DS</li></dd> 317 <p>
156 <dd><li>Input DSが全て揃った時点で実行される。そろったかどうかはTaskが持つ。</dd> 318 ほしかったらmmapして、いらなくなったらmunmapすればよい。
157 <dd><li>DSには持ってるTaskへのポインタが必要(Cerium、Aliceと同じ)</dd>
158 <dd><li>接続って具体的にどうやる？Ceriumで言うcreateTaskに相当する？</dd>
159 </div>
160
161
162 <div class='slide'>
163 <h2>Persistent DS</h2>
164 <p>
165 Persitent DSはkey(URL)を持つ。keyを持ってるので、書き込みは
166 <pre class="code">
167 goto write(ds);</pre>
168 でよい。DS自体がURLを持っているので、goto write(ds, key);とかしなくて良い。
169 </p>
170 <p>
171 ? ds->nextは即座に実行される。ds->nextがなければ、そこで計算は終了。
172 </p>
173 <p>
174 読み込みは、
175 <pre class="code">
176 goto read(ds);</pre>
177 すれば良いだけだが、ds->nextに次に行う演算が入っている。
178 </p>
179 </div>
180
181
182
183 <div class='slide'>
184 <h2>Meta Space, Core Space</h2>
185 <table>
186 <tr>
187 <th><img src="images/meta_space.png" width="400"></th>
188 <th align="left">
189 <p>Meta SpeceにはTaskのScheduleを行うScheduler、
190 DSの管理を行うDS Manager、Taskの生成を行うTaskManager(Ceriumと同等の機能)がある。
191 </p> 319 </p>
192 </th> 320 </th>
193 </tr> 321 </tr>
194
195 <tr>
196 <th><img src="images/core_space.png" width="400"></th>
197 <th align="left">
198 <p>CoreSpaceにはCS間の遷移を行うDispatcher、同期制御を行うsynchronizer、
199 Memory Spaceの制御を行うSegment Manager(OSやOpenCLにもある)がある。
200 Segment ManagerはMemory間のコピーも行う
201 </p>
202 <p>
203 このDispatcher、Segment Manager辺りを担当することになる？
204 </p>
205 </th>
206 </tr>
207
208 </table> 322 </table>
209 </div> 323 <ul>
210 324 <li>free list上でフラグメンテーションが起きにくくなった(当たり前)</li>
211 <div class='slide'> 325 <li>メモリの無駄が少ない<br>
212 <h2>Memory Manager</h2> 326 大きなメモリは同じサイズでもう一度mallocされる可能性は低いので、
213 <table> 327 使わなくなったらすぐOSに返却するのは正しい</li>
214 <tr> 328 </ul>
215 <th><img src="images/memory_manager.png" width="500"></th> 329 </div>
216 <th align="left"> 330
217 <p>
218 DataSegmentは2^n allocatorで配分される。それらは</p>
219 <ul>
220 <li>Physical Memory</li>
221 <li>Cache Memory</li>
222 <li>Parsistent Memory(Disk or Flash)</li>
223 </ul>
224 <p>
225 にMappingされる。
226 </p>
227 <p>
228 Persistent Space はDSの非破壊なBlanced Binary Treeにより構成される(jungle)
229 </p>
230 </th>
231 </tr>
232
233 </table>
234 </div>
235
236
237
238 <div class='slide'>
239 <h2>とりあえず取り掛かれること</h2>
240 <p>ここらへん？</p>
241 <ul>
242 <li>Segment Manager(Memory Allocator)
243 <li>Data SegmentのNon Destructive Tree
244 <li>TaskManager(Ceriumと同等の機能)
245 </ul>
246 </div>
247
248 </div> <!-- presentation --> 331 </div> <!-- presentation -->
249 </body> 332 </body>
250 </html> 333 </html>