TLB means "translation lookaside buffer", but that's still not very clear. I think a more "correct" name would be "Virtual-to-Physical address cache", since that's kinda what it is.

The TLB keeps a list of the last-accessed physical addresses (and the virtual addresses the map to), and it resides in the CPU. So it provides a performance boost, because without a TLB, the physical addresses would have to be looked up in the page-tables (which are stored in relatively-slow main memory).

Call me ignorant or perhaps naive in the land of VM, but what sorts of apps are huge pages aimed at?

I personally can think of three scenarios, but I don't know if I'm talking out my hindside:

• Scientific apps with gigantic working sets. (Think weather sims on a Beowulf cluster, or even a big Spice run on a single workstation.)
  
• Mappings for large, fixed entities, like X's frame buffer and your video card's 64MB, not-going-anywhere-especially-not-to-swap onboard video RAM.
  
• Mappings for shared-with-everyone libraries, such as libc. (Would require special ld.so support, wouldn't it? Also would require moving all the COW stuff within libc to localized areas, away from the bulk of libc. I'm thinking COW and huge-page are a bad mix.)
  

FWIW, the reason I mention libc is that a simple "grep libc- /proc/*/maps | grep -v rw" turns up a huge list on even my mostly-quiescent box. A typical entry looks like so:

42000000-4212c000 r-xp 00000000 03:05 72290 /lib/i686/libc-2.2.5.so

If you notice, about 1.2MB is covered by libc. This same range is mapped by ALL the processes. This range could be covered by one 2MB or 4MB page, right? (That is, assuming the "rw" section that abuts it is moved outside the range covered by the single 2MB or 4MB huge-page.) Unless I'm smoking something, wouldn't that trade about 300 pages for 1? What would be the drawbacks, aside from the fact you now wouldn't be able to swap libc? (Arguably, if one library is kept in memory, shouldn't it be libc?)

--Joe