> That's not entirely true. We have a dynamic pool now, thanks to Adam > Litke [added to Cc], which can be treated as a high watermark for the > hugetlb pool (and the static pool value serves as a low watermark). > Unless by hugepages you mean something other than what I think (but > referring to a 2M size on x86 imples you are not). And with the > antifragmentation improvements, hugepage pool changes at run-time are > more likely to succeed [added Mel to Cc]. Things are better than I thought ... though the phrase "more likely to succeed" doesn't fill me with confidence. Instead I imagine a system where an occasional spike in memory load causes some memory fragmentation that can't be handled, and so from that point many of the applications that relied on huge pages take a 10% performance hit. This results in sysadmins scheduling regular reboots to unjam things. [Reminds me of the instructions that came with my first flatbed scanner that recommended rebooting the system before and after each use :-( ] > I feel like I should promote libhugetlbfs here. This is also better than I thought ... sounds like some really good things have already happened here. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |