vmalloc

	vmalloc用の仮想アドレス空間と必要な物理ページを確保する。
	物理ページはBuddySystemから確保。
	連続ページになるとは限らない。
	PTEの設定は遅らせるので、vmalloc()で取得した領域にアクセスすると
	一旦Pagefaultが発生する。


vmalloc用仮想アドレス空間の管理
	vmlist
	+------+      +------+
	|      |----->|      |----->
	| addr |      |      |
	| size |      |      |
	+------+      +------+

	各仮想アドレス空間に対して、どの物理アドレスにマッピングされているかは
	本テーブルではわからない。
	仮想<-->物理アドレスの対応は下記、init_mm参照のこと。


カーネル用PTEテーブル管理構造体
init_mm
	本構造体に登録されているPGDにより、vmallocの仮想アドレスに対応する
	物理アドレス(物理ページ)を管理する。

	<-- これはあくまで参照用？
	CPUが本当に参照しているわけではない。
	ページフォルトが発生したときに、本参照用テーブルから
	本当の変換テーブルに設定することで
	実際に物理ページが割り当てられる？

	余計なTLBのFlush等を削減するため？


vmalloc()
	get_vm_area()
		vmlistに指定したサイズ分の仮想アドレス空間のvm_structを挿入する

	vmalloc_area_pages()
		pmd_alloc()
			i386ではPMDが無いので、実質なにもしない。
		alloc_area_pmd()
			pte_alloc(&init_mm, pmd, address) <-- PTEを作成する
				pte_alloc_one_fast()
				pte_alloc_one()
					get_free_page(GFP_KERNEL) <-- PTE用にBuddySystemから1ページ取得

			alloc_area_pte()
				alloc_page() <-- BuddySystemから1Page取得
				pte_alloc()で作成したPTEを設定する(割り当てられた物理Pageを指すようにする)。
				<-- サイズ分ループさせるので
				    物理的に連続ページにはならない。

				<-- 物理ページ割り当てを遅らせたりはしない？？？
					キャッシュに登録しているだけ？
					物理ページの確保はしてあるが、PTEの設定を遅らせている？

	flush_tlb_all()


[メモ]
	vmalloc()で割り当てられた物理ページはカーネル空間(0xc0000000〜)からも
	アクセスできる(ストレートマッピングは変更されないため)。