x86_64 virtual memory map
in [Kernel]
|
Prev: [PATCH][v2] cfq-iosched: Add additional blktrace log messages in CFQ for easier debugging.
Next: [GIT PULL] ext4 fixes
From: hayfeng Lee on 24 Mar 2010 22:30 Hi,folks. Recently I'm studying some things of x86_64 on Linux. And the virsion is 2.6.18.8. From the document of Documentation/x86_64/mm.txt,I found the mapping method for x86_64 virtual memory map. I want to know ,why use this method for virtual memory mapping? ----------------------------------------------------------------------------------------------- 1 2 <previous description obsolete, deleted> 3 4 Virtual memory map with 4 level page tables: 5 6 0000000000000000 - 00007fffffffffff (=47bits) user space, different per mm 7 hole caused by [48:63] sign extension 8 ffff800000000000 - ffff80ffffffffff (=40bits) guard hole 9 ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of all phys. memory 10 ffffc10000000000 - ffffc1ffffffffff (=40bits) hole 11 ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space 12 ... unused hole ... 13 ffffffff80000000 - ffffffff82800000 (=40MB) kernel text mapping, from phys 0 14 ... unused hole ... 15 ffffffff88000000 - fffffffffff00000 (=1919MB) module mapping space 16 17 The direct mapping covers all memory in the system upto the highest 18 memory address (this means in some cases it can also include PCI memory 19 holes) 20 21 vmalloc space is lazily synchronized into the different PML4 pages of 22 the processes using the page fault handler, with init_level4_pgt as 23 reference. 24 25 Current X86-64 implementations only support 40 bit of address space, 26 but we support upto 46bits. This expands into MBZ space in the page tables. 27 28 -Andi Kleen, Jul 2004 I urgently want to know the answer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 26 Mar 2010 00:40
hayfeng Lee <omycle(a)gmail.com> writes: > Hi,folks. > Recently I'm studying some things of x86_64 on Linux. And the virsion > is 2.6.18.8. From the document of Documentation/x86_64/mm.txt,I found > the mapping method for x86_64 virtual memory map. I want to know ,why > use this method for virtual memory mapping? > > ----------------------------------------------------------------------------------------------- > 1 > 2 <previous description obsolete, deleted> > 3 > 4 Virtual memory map with 4 level page tables: > 5 > 6 0000000000000000 - 00007fffffffffff (=47bits) user space, different per mm > 7 hole caused by [48:63] sign extension > 8 ffff800000000000 - ffff80ffffffffff (=40bits) guard hole > 9 ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of > all phys. memory > 10 ffffc10000000000 - ffffc1ffffffffff (=40bits) hole > 11 ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space > 12 ... unused hole ... > 13 ffffffff80000000 - ffffffff82800000 (=40MB) kernel text mapping, > from phys 0 > 14 ... unused hole ... > 15 ffffffff88000000 - fffffffffff00000 (=1919MB) module mapping space > 16 > 17 The direct mapping covers all memory in the system upto the highest > 18 memory address (this means in some cases it can also include PCI memory > 19 holes) > 20 > 21 vmalloc space is lazily synchronized into the different PML4 pages of > 22 the processes using the page fault handler, with init_level4_pgt as > 23 reference. > 24 > 25 Current X86-64 implementations only support 40 bit of address space, > 26 but we support upto 46bits. This expands into MBZ space in the page tables. > 27 > 28 -Andi Kleen, Jul 2004 > > I urgently want to know the answer. We can't give you the answer unless you give us the question, and enough context that the question makes sense. I recommend looking up the AMD and possibly the intel architecture documents on x86_64. They very completely cover what the processors can do and are freely available online. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |