|
⇤ ← Revision 1 as of 2006-06-07 16:59:40
Size: 488
Comment:
|
Size: 1425
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| * STREAM and hugetlb is a huge issue unless you have chipset level interleave no matter what | |
| Line 5: | Line 6: |
| * mmap of a file that is partially in cache already * mmap of a file that then gets replaced on disk (say glibc text and then glibc gets upgraded to a newer version) * MAP_GROWSDOWN for stacks including automatic growth * mprotect to executable (scenario: dlopen of a shared lib that requires executable stack, causing all thread stacks to be mprotected executable) * write() of mmaped area to the same file at an offset either inside or outside the same 2Mb page * same but for an O_DIRECT write * same but for AIO write * sendfile() of a non-4Kb region * truncate of 4Mb mmaped file to 1Mb, then truncate to 1.5Mb then 0.5Mb (creates a sparse file) * mmap of a 2Mb region in 2 parts: first 1Mb gets mmaped writable private, second 2Mb gets mmaped shared writable; then write a few bytes to each part |
Corner cases are slightly non-obvious problems implementing huge pages. If you think of one, please archive it here so it doesn't come back and bite us later.
NUMA-aware allocation - don't want all the memory accesses going through one controller! See [http://www-941.ibm.com/collaboration/wiki/display/LinuxP/Tuning+stream+with+libhugetlbfs IBM's page about tuning Stream].
- STREAM and hugetlb is a huge issue unless you have chipset level interleave no matter what
- Fork of an application with huge pages when no huge pages are left - must fail over to small pages.
- mmap of a file that is partially in cache already
- mmap of a file that then gets replaced on disk
- (say glibc text and then glibc gets upgraded to a newer version)
- MAP_GROWSDOWN for stacks including automatic growth
- mprotect to executable (scenario: dlopen of a shared lib that
- requires executable stack, causing all thread stacks to be mprotected executable)
- write() of mmaped area to the same file at an offset either
- inside or outside the same 2Mb page
- same but for an O_DIRECT write
- same but for AIO write
- sendfile() of a non-4Kb region
- truncate of 4Mb mmaped file to 1Mb, then truncate to 1.5Mb
- then 0.5Mb (creates a sparse file)
- mmap of a 2Mb region in 2 parts: first 1Mb gets mmaped writable private,
- second 2Mb gets mmaped shared writable; then write a few bytes to each part