path: root/init.c
diff options
authorAdam Litke <agl@us.ibm.com>2008-08-05 20:48:21 +0000
committerAdam Litke <agl@us.ibm.com>2008-08-05 20:48:21 +0000
commitf9456b5f72ce0310884084c9e25c4cbfb4f57ca2 (patch)
tree5769cf28802db454b0d85de532d8ee746823f390 /init.c
parent56f74e9b51f9bce83cb18e0c9a9f82bbe6da8ead (diff)
[RFC] Use the kernel version number to identify kernel functionality V2
Historically, libhugetlbs has relied on kernel features that either: have been known to exist in all supported kernel versions, or are easily detected. As of kernel version 2.6.27-rc1, a new crucial feature has been added that is not possible to reliably detect. Huge page mappings created with the MAP_PRIVATE flag will have huge pages reserved up-front. With private reservations in effect, it is safe to allow demand-faulting of the HUGETLB_MORECORE heap which can lead to dramatic performance improvements on NUMA systems. This is only safe behavior in the presence of private reservations. The only way to identify that a kernel has private reservations support is to examine the kernel version to see if it is more recent than when the feature appeared. I am well aware of the drawbacks of using the kernel version to affect library behavior but I don't see any alternative. I would suggest that the kernel version should be used only in cases when there is no alternative. How it works ============ Kernels are assumed to have a mandatory base version x.y.z (eg. 2.6.17) and one optional modifier: a post version (stable tree x.y.z.q) or a pre version (x.y.z-{preN|rcN}). All other version appendices (such as -mmN) are ignored. The following ordering rules apply: x.y.z-rc(N) < x.y.z-rc(N+1) < x.y.z < x.y.z.(N) < x.y.z.(N+1) When libhugetlbfs initializes, the running kernel version is probed using uname. A list of feature definitions is scanned and those with a minimum kernel version have that version compared to the runninng kernel. If the running kernel is found to be equal to or greater than the minimum required kernel version, a bit in a feature mask is set to indicate the presence of the feature. A feature can be later checked for by using a simple function that checks the bitmask. Changes since V1 (Thanks Andy Whitcroft and Mel Gorman): - Fixed feature_mask handling - Readability improvements
Diffstat (limited to 'init.c')
1 files changed, 1 insertions, 0 deletions
diff --git a/init.c b/init.c
index e1415f5..51ad27c 100644
--- a/init.c
+++ b/init.c
@@ -22,6 +22,7 @@
static void __attribute__ ((constructor)) setup_libhugetlbfs(void)
+ __lh_setup_features();
#ifndef NO_ELFLINK