Home / server / Questions / 487662
In Process
user164485
Asked: 2013-03-14 19:29:38 +0800 CST

About huge page and translation Lookaside Buffer

  • 772

they confuse me.

huge page: the way to manage physical memory of OS kernel, it is split huge page by kernel for reduce the index number in page table.

I get it from : https://stackoverflow.com/questions/1973473/difference-between-cache-and-translation-lookaside-buffertlb

Translation Lookaside Buffer: A Translation lookaside buffer(TLB) is a CPU cache that memory management hardware uses to improve virtual address translation speed.

huge page (OS level) translation Lookaside Buffer(CPU cache)

https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt the document said , /proc/sys/vm/nr_hugepages indicates the current number of "persistent" huge pages in the kernel's huge page pool.

In my server,

echo 40 > /proc/sys/vm/nr_hugepages   
cat /proc/meminfo | grep -i hugepage   
AnonHugePages:   1675264 kB   
HugePages_Total:      40   
HugePages_Free:       40  
HugePages_Rsvd:        0   
HugePages_Surp:        0   
Hugepagesize:       2048 kB

next, it's my questions.

  1. What's the mean about AnonHugePages ? why is 1675264KB ? I think there are 40 x 2048KB huge page memory. I can't understand.

  2. Why I can't modify Hugepagesize ? in theory, kernel could modify the size. maybe just no the interface in kernel.

  3. How can I get the Translation Lookaside Buffer size? I think system kernel know the size, because the kernel will use it .

I hope I express clearly.
:)

performance

2 Answers

  1. AnonHugePages are used by the kernel for "transparent hugepages". They are accounted for separately from the "HugePages_Total" that is listed in meminfo.

    Originally, to use huge pages your application had to support them directly. Java does, Oracle does. I'm sure there are other big memory users that use them. They also must be manually configured. Alternately, your application had to use hugetlbfs, which is a particular interface to using hugepages. hugetlbfs uses the system pool of "regular" hugepages like apps that use the huge pages directly.

    More recently, there is an addition of transparent hugepages. In theory, this gives you the benefits of hugepages without the cost of modifying your applications. A kernel thread called khugepaged sweeps through memory and merges standard pages into hugepages. Red Hat 6 adds transparent hugepages. I do not know what other distros have it, but i do know that this is ongoing work.

    In practice, this sometimes causes problems with system responsiveness. I had issues with a system running lots of memory-heavy java apps (which were not configured manually to use hugepages). The system has 128GB of RAM and runs RHEL6. After it was up for 90 days or so, memory would become fragmented. At this point we'd have system pauses of as long as a minute or two, presumably memory was locked while khugepaged ran. Disabling transparent hugepages made it better immediately. We still had some performance problems, but configuring java to use manual hugepages fixed things right up.

    This presentation has a good, in-depth explanation of hugepages:

    http://www.slideshare.net/raghusiddarth/transparent-hugepages-in-rhel-6

    • 2

  2. The TLB size depends on the make and model of the CPU. The size of huge pages is fixed ( by the CPU ) at 4 MiB or 2 MiB when PAE is enabled. The AnonHugePages count there I can't make sense of since if there really are 40 huge pages, that would be 80 MiB, which is nowhere near that number.

    • 0