MAP＝関数。
「V→P U 空集合」の順番にアクセスする
V＝仮想アドレス
P＝物理アドレス
U＝ユニオン
[たとえ話]]
起き上がって仕事をしようとしても、今まで休んでいたから、
以前使っていたメモリ使用領域はDiskに追い出されていることがある
[想定されるケース]
MAPで物理アドレスが求まる場合と
物理的なメモリには無くてDiskに追い出されている場合(→空集合へいくケース)がある。
//深い話については3年次のOSの授業でやる。
！！表は試験に出ないけど、表の理解はとても大事！！
[Pageについて]
今の多くのコンピュータは4kB(4096=12bit)単位でメモリ領域間を移動する。
1pageが標準。
2^10≒1,000
2^20≒1,000,000
ページは読み書きしたいアドレスが属する番号を示している。
[仮想アドレス]
仮想アドレスのうち
上位20bitは残る→PPNへ
上位20bitを使って、メインメモリの中にキャッシュされているページテーブルの場所を示して、
ページテーブルのエントリーを見に行く。
※ページテーブルは必ずどこかにある！
[validの役割]
validが立っている(valid=1)と、
validが立っていない(valid=0)場合がある
→ページフォールトになるととても時間がかかる。
virtualアドレスをコンピュータの中のアドレスに変換する(=phisicalアドレスを作る)。
[仮想アドレス下位]
下位12bitは上位20bitで得たアドレスを読み書きするのに使用する。
[単語説明]
MMU＝Memory Management Unit :メモリを管理するユニット
VA=Virtual Address :仮想アドレス
PTEA=Page Table Entry Address :情報のありかを示す場所。(一種の索引で「どこを見るか」ということ)
PTE= Page Table Entry :情報の中身？
PA=Physical Address:物理アドレス
[MMUの動作]
一般的に一往復多い(②と③の部分)→もったいない。
最近のプロセッサーはそこを頑張ってなんとかしようとしている cf."TLB"
キャッシュに当たったとしても②と③はもったいない。
[悲惨場合]
1. ②でMMUにない場合
2. ④Exceptionで"Page faultだった"という報告をする。
→その後の作業はOSに任せる
3. victim pageをDiskに追い出しnew pageをキャッシュに置く。
→この動作もまた、とても時間がかかる
(補足)
ページテーブルのアドレスがあればMMUに帰ってくる。
PAもキャッシュにあればProcessorを介してMMUに戻る。
無ければL２やMemoryにアクセスしていく。
[往復問題]
L1にあったとしても、L1キャッシュが込んでくると、
他のメモリ参照のせいで、キャッシュしたのが追い出されてしまう。
また、読み出すのに少なくとも1サイクルの遅れがある。
・MMUの中にキャッシュがあればよいのではないか？
→(HOTな話題)TLB = Translation Lookaside Buffer
small hardware cache in MMU
ハードウェアでそもそもメモリを扱おうとするプロジェクト？
ページテーブルは大きい。1Pは4kだから運十万ぐらいにいく。
だからそのうちの、とってもよく使う部分だけをMMUに入れてしまおうという内容。
[第2ラウンドの話]
TLB hit
TLBに物理アドレスと論理アドレスの関係の表がキャッシュされていたら、
VPN(= Virtual Page Number)で聞き、PTEで返してもらう。
結果：1サイクル得する。
不幸にもTLBにキャッシュされていなかったら、キャッシュメモリに行って2往復する。
なるべくメモリをうまく使えるプログラムを作って、VAの無いようにする。
実際にはTLB MissはあまりMissらない。
→何故？→教科書参照
[64bitと32bitについて]
1Pは4kB単位
最近の64bit(athronとか)は、全部のbitを使うわけではない。
PTEが４バイトで済む→物理メモリの何テーブル目かが分かる。
64bitマシーンはhardwareサポートしている。256GBある？→ただし効率が悪い。
→表というのは大きくなりすぎると、検索するのが大変。
→索引を幾つかに分ける。索引のための索引を作る。cf.Level1 table ⇔ Lebel2 tables
たくさんある索引のうちのどの索引にあるか調べる。
→2 Lebel Tables、一般的なpentiumでは大体用いられている。
256GBの使ってないものを置く必要性をなくしている？
[Case study]
-Pentium系のマシンはどうなっているのか？-
INTEL P6
core2とかpentiumとかその辺のマシンについて
Pentium →93年に出来た。 cf.教科書参照15-213, F'06
2～3年前はPentium4
ただし、pentium4はpentium3にはない問題が浮上した
→発熱が大きい
INTELもここら辺で気付いた。
・4GHzを出そうというプロジェクトを辞めて、Pentium3に戻り、拡張してCore2duoを作った。
→熱の問題に対処した。
dual core→一個のCPUにたくさんのプロセッサを乗っけること。
だから、Pentium4を勉強する必要はあまり無い。
※技術が進歩しているので教科書の具体値は微妙に違う。
[P6 Memory System][
この図はそれほど勉強する必要は無い。
[Review of Addreviations] 略語集
[Overview of P6 Address Translation]
これが理解できたら大丈夫。
CPUは左上にある。
一周するのには、様々なルートがある。→様々なサイクル数が考えられる。
Virtual Addressは上と下で20bit=VPN, 12bit=VPOに分かれている。
VPOはPhysical Addressを読み書きする。＝PPO
PPNとPPOでキャッシュを見に行く。
CO＝Cache offset (5bit)
L1は一個ずつの箱が32bit?
全部で512個
cf.車両。店員512名。隣の列車には移れない。
CI = Cache Index :索引
CT = Cache Tag :聞きに行くためのタグ
見つからなかったら、残念ですね。ということでL2 and DRAMに行く。
→とても遅くなります。
[VAの上位20bitの部分について]
ページテーブルはどういう風になっているのか。
1ページ＝12bit
あまり利用されないPage Tableは遠いところに追い出される。
PDBR=Page Directly Base Register
[今日のスライド9P]
さっきの絵の左下の拡大図
20bitをさらに10bit/10bitに分けて、
VPN1でLevel 1を、VPN2でLevel2 Tablesを示す。
レベル１のエントリ…この部分はあまり理解しなくても良い。
//省略
[大事なところ＝一番うまくいくケースについて考える]
VPNがPPNを効率的に引ける場合。
TLBはキャッシュと大体同じ構成をしている。
本当に書いているかどうかはTLBTと一致しているかどうかで調べる。
店員は64ページ。TLBはほぼ確実に当たってほしい。
[製作者の意図する理想]
64P×4kB=256kBぐらいのメモリアドレス空間はとても早く実行してあげましょう
それ以外は遅くなってしまうでしょう。
TLBIで何号車にいるかを調べる。
TLBTで比較。
コレがうまくいくと、あとはキャッシュにいく。
アドレスを計算するためのキャッシュ＝TLB
データを計算するためのキャッシュ＝L1,L2,Memory and so on
VPNの仮想番地から物理番地を求めるにはある程度の手間がかかる。
キャッシュを求めるためには、またある程度の手間がかかる。
キャッシュの切れ目に注目すると、
→一致している！
→VPOはPPOと変わらないので、VPIがごちゃごちゃやっている間にキャッシュの表を引く作業を実行している。
[CPUの見方]
キャッシュがどれだけ乗っていたか。
テストプログラムからassociabiltyを見ている。
例、先生のCPU
L1は32kB
L1 8way
Line size 64kB
一個64biteが８個並ぶ。←キャッシュセット
512kB/setが縦に64set並んでいる。
[TLBの話]
L1 D-TLB
Entries 128
Associavilty 4-way
□□□□
↑Entry
コレが
□□□□
□□□□
…
□□□□
↑32setsある。
[何故ストライドアクセスでスパイクが起こるのか？]
//Page2参照
ストライド1024kBで何が起こっているのか。
----------------------------------
・stride 1024=1024*int=4kB
4kB毎にアクセスする→1 pageあたり一個のIntegerしか読まない。
つまり、全部で256 pageにアクセスする。
256 pageの命令でload/store命令を起こす。
つまり、
129個目をアクセスするときは、先客を追い出す必要がある。
よって、後半のアクセスはTLBは外れて追い出しながらアクセスしなくてはならない。
→よって、2回目以降の計測は、TLBがはずれまくるゾーンとなってしまう。
・stride 512 = 512*int = 2kB
→1 page(4kB)あたりにintegerが２個ある。
→128 page分のアドレスが作られる。
128 pageの空席がある。
→for loopなので、制御命令も含めると微妙に追い出されてしまうこともあるが、ほぼ全員座れる。
TLBは完全に満杯の状態だと右上がりに上昇する。
規則的な(64byte毎の)スパイクについて
stride 64:256kBおきにアクセスしている。
TLBに関しては問題は多分起きていないだろう
→他の理由があるはずだ。
さっきのアドレス表を思い出す。
PA 64
□□□□←6bit
↑6bit
全部で64×8＝512 lines (entries)
つまりL1キャッシュに８つの座席がある？
64bit = int 16個分
-------------------
■■■■
-------------------
□□□□
-------------------
□□□□
-------------------
□□□□
-------------------
■■■■
…
4lineおきに使われる。→全てのlineが有効活用出来ない
最初：L1cacheを追い出しながらやる。
２回目の測定を始めると、後半を追い出しながら前半が入って息。
L1cacheの追い出し、追い出されが毎回起きている。
同様の理由で、stride 128とかも起こる。
画像を弄るときは1024*1024よりは1025*1025にした方が良い。
→2のべき乗は要注意
試験の話。
PC以外なら何でも持ち込み可能。
[質疑応答]
・２のべき乗の問題について
000/000000
100/000000
1000/000000
1100/000000
…
↑下位6bitは使われない。→使われないsetが存在する。
0 件のコメント:
コメントを投稿