川の流れのように‥(Eiji Ota's Weblog)

UltraSPARC sfmmu - 生き残るSpitfireの精神 UltraSPARCとともに

UltraSPARCのMMU その名は、「ガミガミ女」のMMU...

前回NiagaraではMMU用のTrapが違うようだっていうお話をしましたので、その"流れ"で今回はUltraSPARCのMMUについて、ちょっとお話しましょう。

前回は、確か、次の２つのトラップ(TL = 0の時)が従来のUltraSPARC用のMMUトラップ…っていうお話をしたんでしたよね？ 今回はその続き…。

さぁ、始まり始まり…。^_^

ITLB_MISS(tt0);	/* 064 instruction access MMU miss */
DTLB_MISS(tt0);	/* 068 data access MMU miss */

と言いつつ、さて皆さん、出だしからいきなり脱線です ^-^ UltraSPARC用のMMU処理はsfmmuと呼ばれているんですけど、このsf...というのは、初代のUltraSPARC CPU, UltraSPARC-IのコードネームがSpitfireであったことからきたもの - すなわちSpitfire MMUの略記なんですねぇ。

スピットファイアというと、あの第２次世界大戦中のイギリスの名機を思い出す方もいるのでは？ バトル・オブ・ブリテンで、ドイツのメッサーシュミットと互角の戦いを繰り広げた戦闘機ですねぇ。子供の頃、スピットファイアやメッサーシュミット、零式戦闘機なんて聞くと、何か凄いもののように思えて、胸がドキドキしたものです。^O^

もちろん、今回はその戦闘機うんぬんということでは全然ないんですが、…全然今まで知らなかったのですが…、このスピットファイア、「ガミガミ女」っていう意味(注1)があるらしいんですよねぇ。('-')

つまり、UltraSPARCのsfmmuって、ガミガミ女のMMUっていうことですよね。この新鮮な驚きっ！ （← これが言いたかった (^-^;)>）

それでは、しょっぱな早速脱線したところで、このTLBミスって何？っていうところをまず説明しましょう！^.^

MMU(= Memory Management Unit)をサポートしているCPUは、ご存知のようにメモリにアクセスする時にVA(= Virtual Address：仮想アドレス)でアクセスすることができます。でも、メモリの実体は、PA(= Physical Address：物理アドレス)で番地付けられていますよね。プログラムがメモリの番地をVAで指定してきた時に、「誰か」がVAからPAに変換してCPUに本当の番地を教えてあげないといけないわけです。そしてそれをMMUがやっている…というわけですね。それで、プログラムは仮想アドレスを番地として使っても問題ないわけですね。

それでは、MMUはどのようにして仮想アドレスを物理アドレスに変換しているかというと、TLB(= Translation Lookaside Buffer)という変換テーブルを用意していて、そのテーブルに該当のアドレスがないかを検索します。見つかったら、その情報を元に変換してやるわけです。X86アーキテクチャでは、Page Translation Cacheと呼ばれてたりしますから、こちらの方が馴染みがある方もいるでしょうね。

まぁ、運良くTLBに探しているアドレスがあればいいんですけれど、世の中そう甘くな〜いっ。いつもあるとは限らないお金とアドレス、必要な時に見つからない。じゃぁ、どうすればいいのぉ？ そう、そう、そういう時は、嘆きたくなりますよねぇ、なんとかしてぇぇって。 MMUが嘆きたくなるその時、CPUがtrapしてくる - そう、それがこのTLBミス・トラップなんです。(^-^;) .oO (ちょっと苦しかったかしら…)

実際には、TLBミスが発生した時にどうするのかっていうのは、CPU次第。X86アーキのように、カーネルがPage Directory Table等々のTableを用意してあげて、CPUがTable Walkingを行って捜し出すものもあれば、CPUがtrapをあげてカーネルに教えて頂戴って言ってくるのもあります。

UltraSPARCは後者を採用しているわけなんですね。X86アーキに慣れている人は、なんか面倒だなって感じるかも知れないけど、この手法は結構ポピュラーな方法です。Andrew S. Tanenbaum教授の(有名な)著書"Operationg Systems Design and Implementation"にもSoftware TLB Managementとして説明(注2)されていて、数々のRISC CPUに採用されている方法でもあるんですね。(*_*)

さぁ、相変わらず前置きが長い私です…さっさと本題に入りますと(^.^;)(汗汗)、このITLB_MISSとDTLB_MISSは、今まで説明したように、基本的にはMMUがTLBを使って検索したが見つからなかったアドレス変換を、Nucleusが肩代りしてあげるためのものです。

ほぼ双子の二人なITLB_MISS()とDTLB_MISSですから、どちらか一方、ではDTLB_MISS()の方をみてみましょうね？(インストラクションには実行権が必要なので、その辺りが違ったりしますが、まぁ気にしないことにしませう)

NucleusにはTSB(= Translation Storage Buffer)と呼ばれる領域があって、これでTLBエントリ(TTE)を管理しています。いわば、Nucleusが管理しているDirect Map Cacheのような"感じ"なんですが、MMU miss trapが発生しますと、CPUはこれかなって思う8Kページの情報(TSBのポインタやTag情報)を持ってシステムにtrapをかけてきますので、この情報を元に、TSBからアドレス変換情報を引っ張ってきて、TLBを更新してあげる…というのが、このUltraSPARCのMMU miss trapの基本処理です。(^-^)

それでは、説明はそれぐらいにして、実際のコードをみてみましょうね。

/*
 * Needs to be exactly 32 instructions
 *
 * UTLB NOTE: If we don't hit on the 8k pointer then we branch
 * to a special 4M tsb handler. It would be nice if that handler
 * could live in this file but currently it seems better to allow
 * it to fall thru to sfmmu_tsb_miss.
 */
#define	DTLB_MISS(table_name)						;\
	.global	table_name/**/_dtlbmiss					;\
table_name/**/_dtlbmiss:						;\
	HAT_PERCPU_DBSTAT(TSBMISS_DTLBMISS) /* 3 instr ifdef DEBUG */	;\
	mov	MMU_TAG_ACCESS, %g6		/* select tag acc */	;\
	ldxa	[%g0]ASI_DMMU_TSB_8K, %g1	/* g1 = tsbe ptr */	;\
	ldxa	[%g6]ASI_DMMU, %g2		/* g2 = tag access */	;\
	sllx	%g2, TAGACC_CTX_LSHIFT, %g3				;\
	srlx	%g3, TAGACC_CTX_LSHIFT, %g3	/* g3 = ctx */		;\
	cmp	%g3, INVALID_CONTEXT					;\
	ble,pn	%xcc, sfmmu_kdtlb_miss					;\
	  srlx	%g2, TAG_VALO_SHIFT, %g7	/* g7 = tsb tag */	;\
	brlz,pn %g1, sfmmu_udtlb_slowpath				;\
	  nop								;\
	ldda	[%g1]ASI_NQUAD_LD, %g4	/* g4 = tag, %g5 data */	;\
	cmp	%g4, %g7						;\
	bne,pn	%xcc, sfmmu_tsb_miss_tt		/* no 4M TSB, miss */	;\
	  mov	%g0, %g3		/* clear 4M tsbe ptr */		;\
	TT_TRACE(trace_tsbhit)		/* 2 instr ifdef TRAPTRACE */	;\
	stxa	%g5, [%g0]ASI_DTLB_IN	/* trapstat expects TTE */	;\
	retry				/* in %g5 */			;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	unimp	0							;\
	.align 128

まず、上の青色で表示されたところをみてください。

これがTLB miss Trapの処理の中核部分です。どうですか？ 凄くシンプルですよね？ Tanenbaum教授が「過去はHWでMMUを処理していたが、現代のRISC CPUはそれをソフトで行う…。驚くべきことに、…ソフトで行う処理は非常に効率的…」と記述したところ(正確には注2を見てね)が、正にここ。これをみると、なるほどと頷けるものがありますよね。^-^

赤色で示されたところは、TSBにもない場合や、8Kページではなかった場合、コンテキストが不正である場合などの時に、飛んでいくルーチンです。実際には、色々なケースがあるので一筋縄ではいかないんですよね…^.^;。でも、基本は凄くシンプルってことが見て頂けたでしょうか？ RISCらしさ- シンプルであること - が出ているところ…かも知れませんね。^-^ (8kページ以外や異常系はそれなりに大変だけど…)

そうそう、コメントなんですけれど…

/*
 * Needs to be exactly 32 instructions
 *
 * UTLB NOTE: If we don't hit on the 8k pointer then we branch
 * to a special 4M tsb handler. It would be nice if that handler
 * could live in this file but currently it seems better to allow
 * it to fall thru to sfmmu_tsb_miss.
 */

この、「exactly 32 instructions」 ← ここに前回の疑問の回答がありました！のでご報告。(^-^)v

CPU実装依存のTrap 0x64 (instruction access MMU miss)とTrap 0x68 (data access MMU miss)は、UltraSPARCでは32命令まで使用できることになっているんですね。それに対し、SPARCv9で決められているMMU用のTrap 0x9と0x31は8命令。この違いから来ているみたい。

普通、Trapハンドラのエントリは8命令で記述するんですけれど、例外はWindow Registerを扱うspill/fill/clean_windowトラップ。こちらは、性能に関係することもあって、32命令まで使用できるようになっています。でも、このinstruction access MMU missとdata access MMU missもspill/fill君たちと同じく、32命令なんですね。これで前回の疑問がとけました。(嬉しいっ)

なぜUltraSPARCはMMU用のTrap 0x9と0x31を使用せず、代わりに0x64と0x68を使用することにしたか - それは、TLB miss trapの処理にはスピードが必要なのにもかかわらず、8命令では命令数が足りなくて処理が遅くなってしまうから - ということだったんですね。（うんうん。納得しましたっ）

そういえば、このトラップ番号0x64, 0x68は、それぞれfast_instruction_access_MMU_miss trap, fast_data_access_MMU_miss trapと、やたら長い(^.^)名前で呼ばれていました。（ってすぐ気づけって…。ははは…。(^-^;)> でも分かって良かった）

......

今日は「ガミガミ女」のMMU（← こだわりです'-'） - sfmmuの基本的な部分をさっくり覗いてみました。如何だったですか？ HWではなくSWで処理するMMUの、シンプルな基本デザインとそこからくる処理速度。Tanenbaum教授を驚かせた意外性がここにありました。UltraSPARC-I以降のUltraSPARC達ががそれぞれMMUの実装を変更しつつ(注3)も、この「ガミガミ女」のデザインはしっかり踏襲しています(^.^;)。

......

さて、お知らせです。

実は7/4の独立記念日の休暇を利用して、日本でビザを更新することにしました。生憎ビザ更新には時間がかかることもあり、しばらく日本に滞在することになりそうです（幸か不幸か…ですね(^-^).oO(お刺身食べたい…)）。そんなこともあって、僕のBlogも不定期になりそうなんですけれど、どうかお許し下さいね！ ちょっと予定が分からないので、予めご連絡しておきたいと思いました。それでは。(^v^)

---

◎ (注1) スピットファイアって「ガミガミ女」以外にも色々意味はありそうなのですが…(+_+)

◎ (注2) Tanenbaum教授は、「... In this design, TLB management and handling TLB faults are done entirely by the MMU hardware. Traps to the operating system occur only when a page is not in memory. In the past, this assumption was true. However, some modern RISC machines, including the MIPS, Alpha, and HP PA, do nearly all of this page management in software. .... Suprisingly enough, if the TLB is reasonably large (say, 64 entries) to reduce the miss rate, software management of the TLB turns out to be quite efficient. ...」と説明されています。

引用は、"Operationg Systems Desing and Implementation Second Edition" (ISBN 0-13-630129-9) P.329 から。

◎ (注3) 実はSPARC architectureはMMUの仕様については明確に定めていません。v7では存在せず、v8ではReference MMUがあり、v9ではMMU Requirementが定義されているだけです。V9のMMU Requirementについては、"The SPARC architecture Manual Version 9"のF SPARC-V9 MMU Requirement (P275)を見て貰うとよいと思いますが、他との整合性を満たすための必要な事項等が定められているだけで、そのRequirementを満たすのであれば、実際にはどのようなMMUの実装であってもかまいません。

MMUは性能に大きく関係するところであり、SPARC CPUの設計の見せどころになっています。また近い将来、技術の進歩により実装が変更される場合でも、システムの互換性を損なわず新しい技術を導入できるようになっています。極端な話として、MMUを実装しなくてもArchitecture上は全く問題ありません。ですが、MMUの違いはカーネルの実装で吸収しなくてはなりません。(T-T)

---

Technorati Tag: SPARC
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
Technorati Tag: trap
Technorati Tag: UltraSPARC
Technorati Tag: sfmmu
Technorati Tag: MMU

Posted at 04:38午前 7 02, 2005 by eota in kernel  |  Comments[0]