| |||||||||||||
Huge pages part 1 (Introduction)Huge pages part 1 (Introduction)Posted Feb 19, 2010 12:03 UTC (Fri) by farnz (guest, #17727)In reply to: Huge pages part 1 (Introduction) by nix Parent article: Huge pages part 1 (Introduction)
What you really want (but it's difficult to do sanely on x86) is transparent huge pages. Where possible, the kernel gives you continguous physical pages for continguous virtual pages, and it transparently converts suitable sets of continguous virtual pages to the next size of mapping up when it can do so, and splits large mappings into the next size down when they're not in use, or when there's memory pressure. The pain on x86 is twofold: first, instead of getting to aggregate (e.g.) 16 4K pages into a 16K page, then 16 16K pages into a 256K page, you get to do things like aggregate 1024 4K pages into a 4M page, and 256 4M pages into a 1GB page. Second, typical x86 TLBs are split by page type; so it's not uncommon to have something like the Core 2 Duo, where you have 128 entries for 4K pages, and just 4 entries for 4M pages (Instruction TLB). Given that split, most workloads gain more from having the kernel always in the TLB, than from evicting the kernel in favour of your own code (which would have been in the 4K page size TLB otherwise).
(Log in to post comments)
Huge pages part 1 (Introduction) Posted Feb 19, 2010 14:15 UTC (Fri) by paulj (subscriber, #341) [Link]
Doesn't Linux already use huge pages for the kernel? Or am I misremembering
something?
Huge pages part 1 (Introduction) Posted Feb 19, 2010 14:19 UTC (Fri) by farnz (guest, #17727) [Link] It does. The work being done is for huge pages for userspace, which is a whole different ballgame, and could result in the kernel's hugepage mapping being pushed out of the TLB. If/when someone does the work, it'll need benchmarking not just on the latest and greatest, but also on real-world older systems with more restrictive TLBs, to see if it's a net loss.
Huge pages part 1 (Introduction) Posted Feb 20, 2010 16:33 UTC (Sat) by nix (subscriber, #2304) [Link]
This stuff could presumably autotune, kicking in only on CPUs for which it
is a net win.
Huge pages part 1 (Introduction) Posted Feb 20, 2010 16:31 UTC (Sat) by nix (subscriber, #2304) [Link]
Oh, hell, I forgot about the split TLB. That makes the whole resource
allocation problem drastically harder :/ Still, does the kernel need more than one or two entries? If you're not using hugepages currently, it seems to me that some of those hugepage TLB entries are actually wasted...
|
|||||||||||||