| View previous topic :: View next topic |
| Author |
Message |
wrc1944
Advocate
Joined: 15 Aug 2002
Posts: 2686
Location: Gainesville, Florida
|
 Posted: Sat Dec 03, 2011 3:36 pm Post subject: Transparent huge pages kernel option (pros/cons) feedback? |
 |
|
Anyone have any experience with enabling Transparent huge pages in the kernel? I just built a new 3.1.4 kernel on one of my Gentoo boxes, and enabled it to see if I could notice any advantages. It has been in mainline since 2.6.38, but I just missed it. 
I ran across this, and thought it might be interesting.
http://www.phoronix.com/scan.php?page=article&item=linux_transparent_hugepages&num=1
Page 2 has benchmarks.
Also, a recommended LWN article: Transparent huge pages in 2.6.38 https://lwn.net/Articles/423584/
A quick google search for "transparent hugepage" turns up lots of good info.
A brief quote from one of these:
| Quote: | Processors manage memory in small units called "pages" (which is 4 KB in size in x86). Each process has a virtual memory address space, and there is a "page table" where all the correspondencies between each virtual memory address page and its correspondent real RAM page are kept. The work of walking the page table to find out which RAM page corresponds to a given virtual address is expensive, so the CPU has a small cache to store the result of that work for frequently accessed virtual addresses. However, this cache is not very big and it only supports 4KB pages, so many data-intensive workloads (databases, KVM) have performance problems because all their frequently accessed virtual addresses can't be cached.
To solve this problem, modern processors add cache entries that support pages bigger than 4KB (like 2MB/4MB). Until now, the one way that userspace had to use those pages in Linux was hugetblfs, a filesystem-based API. This release adds support for transparent hugepages ( - hugepages are used automatically where possible. Transparent Huge Pages can be configured to be used always or only as requested with madvise(MADV_HUGEPAGE), and its behaviour can be changed online in /sys/kernel/mm/transparent_hugepage/enabled. For more details, check Documentation/vm/transhuge.txt |
_________________
Main box- ASRock 880GM-LE AM3
Phenom II x6 1090T, 3.2 GHz, 8GB GSkill DDR3 1333mhz
Samsung SATA 500GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.17, gcc-4.7.2, kernel 3.8.11, 3.9.0 |
|
| Back to top |
|
 |
Hu
Watchman
Joined: 06 Mar 2007
Posts: 7618
|
| Posted: Sat Dec 03, 2011 7:13 pm Post subject: |
|
|
| Have you read LWN: Huge pages, slow drives, and long delays? It came out a few weeks ago and highlights one of the potential drawbacks to using transparent huge pages on personal systems. The problem can happen on any system, but headless servers are somewhat less likely to be used in the way that triggers the unpleasant behavior. |
|
| Back to top |
|
|
kerframil
l33t
Joined: 19 Apr 2002
Posts: 710
Location: London, UK
|
|
| Back to top |
|
|
kimmie
Guru
Joined: 08 Sep 2004
Posts: 531
Location: Australia
|
| Posted: Thu Apr 19, 2012 6:41 am Post subject: |
|
|
| For me transparent huge pages on a 3.2 kernel causes long delays (20-30 seconds) using VMWare workstation 8. I have workstation configured to use about 80% of host memory, and not to swap client VM memory. I didn't check to see if changing that configuration helped, but disabling transparent huge pages certainly did. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
