x86_64 Linuxのメモリマップ

まず、
linux-3.4-rc5/Documentation/x86/x86_64/mm.txt

<previous description obsolete, deleted>

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
hole caused by [48:63] sign extension
ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ... 
ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space

The direct mapping covers all memory in the system up to the highest
memory address (this means in some cases it can also include PCI memory
holes).

vmalloc space is lazily synchronized into the different PML4 pages of
the processes using the page fault handler, with init_level4_pgt as
reference.

Current X86-64 implementations only support 40 bits of address space,
but we support up to 46 bits. This expands into MBZ space in the page tables.

-Andi Kleen, Jul 2004

とあり、前から128TBがユーザー空間でお尻の2Gがカーネル空間になっている。
その間に97TBカーネル用にヒープやIO用の空間がある。
x86_64の現在の実装は48ビットのアドレス空間(256T)を持ち、上位16ビットは実質的には意味を持たない。ではアドレスを指定するときにその16ビットはどのような値にしておけばよいかという疑問がでる。インテルのマニュアルではそれに関する記述を見つけられなかったが、AMDのマニュアルには

Bits 63:48 are a sign extension of bit 47, as required for canonical-address forms.

とあり、上のドキュメントの中の

hole caused by [48:63] sign extension

も理解できる。
以上大雑把に理解すると、x86_64のLinuxにおいては64ビットのアドレス空間の先頭の128Tがユーザー空間、お尻の128Tがカーネル空間、その間の領域は無効なアドレスということになる。


Bloggerは基本タグ打ちな世界なんだな。
わかってきたよママン