Pages

(4 intermediate revisions by the same user not shown)

Line 1:

[[File:X86 64.png|x86_64 page table layout|thumb|right]]

Every memory access on a virtual memory requires translation. These translations are typically cached in a Translation Lookaside Buffer (TLB). A TLB miss requires an expensive page table walk, requiring several memory accesses of its own. Larger pages mean more address space translated by each TLB and page table entry, and can thus lead to higher performance.

Linux does not allow deterministic use of huge pages without special privileges, so as not to allow denials of service. Using <tt>madvise(2)</tt> with <tt>MADV_HUGEPAGE</tt> (available since 2.6.38) indicates that the specified memory is suitable for transparent huge pages, but provides no feedback and guarantees nothing. The much newer (6.1) <tt>MADV_COLLAPSE</tt> performs a synchronous best-effort movement into transparent huge pages, and seems refreshingly general and robust. <tt>mmap(2)</tt> can specify <tt>MMAP_HUGETLB</tt> since 2.6.32, but pages must have already been made available by the administrator (the mapping still requires <tt>CAP_IPC_LOCK</tt>). Pages are made available via the [[sysfs]] interface, the kernel command line, or via mounting the hugetlbfs filesystem. This last provides named hugetlb-backed maps. <tt>shmget(2)</tt> since 2.6 has supported <tt>SHM_HUGETLB</tt> for shared memory segments.

==Hardware==

~~[[File:X86 64.png|x86_64 page table layout|right]]~~

* PAE, PSE, PSE36, page tables, PTEs, TLB, MMU, PGD -- explain ''FIXME''

===UltraSPARC===

Line 18:

Line 22:

* "[http://www.ice.gelato.org/apr07/pres_pdf/gelato_ICE07apr_tlbtricks_lameter_sgi.pdf On-The-Fly TLB Generation to Realize Variable Page Size Support on Linux/IA64]" and the [http://www.gelato.unsw.edu.au/IA64wiki/Ia64SuperPages ia64SuperPages] wiki entry at IA64wiki

* "[http://unsworks.unsw.edu.au/vital/access/manager/Repository/unsworks:2417 Transparent Large-Page Support for Itanium Linux]", the master's thesis of Ian Raymond

===PowerPC===

* Mega [http://kerneltrap.org/mailarchive/linux-kernel/2008/3/26/1267024/thread 16G] pages!

* Also 4K, 64K, and 16M at last count...

==Huge Pages==

Making pages larger means fewer TLB misses for a given TLB size (due to more memory being supportable in the same number of pages, due to narrower page identifiers), large mapping/releasing operations will be faster (due to fewer page table entries needing to be handled), and less memory is devoted to page table entries for a given amount of memory being indexed. The downside is possible wastage of main memory (due to pages not being used as completely). A 2002 paper from Navarro et al at Rice proposed transparent operating system support: "[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.2392 Transparent Operating System Support for Superpages]". Applications must generally be modified or wrapped to take advantage of large pages, for instance on Linux (through at least 2.6.30) and Solaris (through at least Solaris 9); FreeBSD (as of 7.2) claims transparent support with high performance.

Making pages larger means fewer TLB misses for a given TLB size (due to more memory being supportable in the same number of pages, due to narrower page identifiers), large mapping/releasing operations will be faster (due to fewer page table entries needing to be handled), and less memory is devoted to page table entries for a given amount of memory being indexed. The downside is possible wastage of main memory (due to pages not being used as completely), and that disk-backed pages have a larger minimum unit to write out when dirty. A 2002 paper from Navarro et al at Rice proposed transparent operating system support: "[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.2392 Transparent Operating System Support for Superpages]". Applications must generally be modified or wrapped to take advantage of large pages, for instance on Linux (through at least 2.6.30) and Solaris (through at least Solaris 9); FreeBSD (as of 7.2) claims transparent support with high performance.

===Linux===

* They were a [http://lwn.net/Articles/40840/ 2003 Kernel Summit] topic, after seeing first [http://kerneltrap.org/node/418 introduction] in Linux 2.5.36 ([http://linuxgazette.net/155/krishnakumar.html LinuxGazette] primer article)

Line 73:

Line 80:

* Weisberg and Wiseman 2009, "[http://www.cs.biu.ac.il/~wiseman/iri2009.pdf Using 4KB Pages for Virtual Memory is Obsolete]"

* "[http://article.gmane.org/gmane.linux.kernel.mm/40182 RFC: Transparent Hugepage support]" Andrea Arcangeli on [[LKML]], 2009-10-26

[[CATEGORY: Hardware]]

[[CATEGORY: x86]]

Pages: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
+[[File:X86 64.png|x86_64 page table layout|thumb|right]]
+Every memory access on a virtual memory requires translation. These translations are typically cached in a Translation Lookaside Buffer (TLB). A TLB miss requires an expensive page table walk, requiring several memory accesses of its own. Larger pages mean more address space translated by each TLB and page table entry, and can thus lead to higher performance.
+Linux does not allow deterministic use of huge pages without special privileges, so as not to allow denials of service. Using <tt>madvise(2)</tt> with <tt>MADV_HUGEPAGE</tt> (available since 2.6.38) indicates that the specified memory is suitable for transparent huge pages, but provides no feedback and guarantees nothing. The much newer (6.1) <tt>MADV_COLLAPSE</tt> performs a synchronous best-effort movement into transparent huge pages, and seems refreshingly general and robust. <tt>mmap(2)</tt> can specify <tt>MMAP_HUGETLB</tt> since 2.6.32, but pages must have already been made available by the administrator (the mapping still requires <tt>CAP_IPC_LOCK</tt>). Pages are made available via the [[sysfs]] interface, the kernel command line, or via mounting the hugetlbfs filesystem. This last provides named hugetlb-backed maps. <tt>shmget(2)</tt> since 2.6 has supported <tt>SHM_HUGETLB</tt> for shared memory segments.
 ==Hardware==
-[[File:X86 64.png|x86_64 page table layout|right]]
 * PAE, PSE, PSE36, page tables, PTEs, TLB, MMU, PGD -- explain ''FIXME''
 ===UltraSPARC===
@@ Line 18: / Line 22: @@
 * "[http://www.ice.gelato.org/apr07/pres_pdf/gelato_ICE07apr_tlbtricks_lameter_sgi.pdf On-The-Fly TLB Generation to Realize Variable Page Size Support on Linux/IA64]" and the [http://www.gelato.unsw.edu.au/IA64wiki/Ia64SuperPages ia64SuperPages] wiki entry at IA64wiki
 * "[http://unsworks.unsw.edu.au/vital/access/manager/Repository/unsworks:2417 Transparent Large-Page Support for Itanium Linux]", the master's thesis of Ian Raymond
+===PowerPC===
+* Mega [http://kerneltrap.org/mailarchive/linux-kernel/2008/3/26/1267024/thread 16G] pages!
+* Also 4K, 64K, and 16M at last count...
 ==Huge Pages==
-Making pages larger means fewer TLB misses for a given TLB size (due to more memory being supportable in the same number of pages, due to narrower page identifiers), large mapping/releasing operations will be faster (due to fewer page table entries needing to be handled), and less memory is devoted to page table entries for a given amount of memory being indexed. The downside is possible wastage of main memory (due to pages not being used as completely). A 2002 paper from Navarro et al at Rice proposed transparent operating system support: "[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.2392 Transparent Operating System Support for Superpages]". Applications must generally be modified or wrapped to take advantage of large pages, for instance on Linux (through at least 2.6.30) and Solaris (through at least Solaris 9); FreeBSD (as of 7.2) claims transparent support with high performance.
+Making pages larger means fewer TLB misses for a given TLB size (due to more memory being supportable in the same number of pages, due to narrower page identifiers), large mapping/releasing operations will be faster (due to fewer page table entries needing to be handled), and less memory is devoted to page table entries for a given amount of memory being indexed. The downside is possible wastage of main memory (due to pages not being used as completely), and that disk-backed pages have a larger minimum unit to write out when dirty. A 2002 paper from Navarro et al at Rice proposed transparent operating system support: "[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.2392 Transparent Operating System Support for Superpages]". Applications must generally be modified or wrapped to take advantage of large pages, for instance on Linux (through at least 2.6.30) and Solaris (through at least Solaris 9); FreeBSD (as of 7.2) claims transparent support with high performance.
 ===Linux===
 * They were a [http://lwn.net/Articles/40840/ 2003 Kernel Summit] topic, after seeing first [http://kerneltrap.org/node/418 introduction] in Linux 2.5.36 ([http://linuxgazette.net/155/krishnakumar.html LinuxGazette] primer article)
@@ Line 73: / Line 80: @@
 * Weisberg and Wiseman 2009, "[http://www.cs.biu.ac.il/~wiseman/iri2009.pdf Using 4KB Pages for Virtual Memory is Obsolete]"
 * "[http://article.gmane.org/gmane.linux.kernel.mm/40182 RFC: Transparent Hugepage support]" Andrea Arcangeli on [[LKML]], 2009-10-26
+[[CATEGORY: Hardware]]
+[[CATEGORY: x86]]