This patch updates the HOWTO file for several changes to the library. Morecore works on IA64 and Sparc64 and should (though it is untested) on SH64.
Add suggestion to NUMA users to select a memory policy that works well with
their selected CPU policy.
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
HOWTO | 26 ++++++++++++++------------
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/HOWTO b/HOWTO
index 083836d..e4ce8e9 100644
--- a/HOWTO
+++ b/HOWTO
@@ -2,7 +2,7 @@ libhugetlbfs HOWTO
==================
Author: David Gibson <[EMAIL PROTECTED]>, Adam Litke <[EMAIL PROTECTED]>, and
others
-Last updated: Monday, July 2nd, 2007
+Last updated: Tuesday, May 13th, 2008
Introduction
============
@@ -46,10 +46,10 @@ You will need a CPU with some sort of hugepage support,
which is
handled by your kernel. The covers recent x86, AMD64 and 64-bit
PowerPC(R) (POWER4, PPC970 and later) CPUs.
-Currently, only x86, AMD64 and PowerPC are supported by libhugetlbfs.
-IA64, Sparc64 and SH64 CPUs can also support hugepages, but are not
-currently supported by libhugetlbfs (support should be easy to add,
-though).
+Currently, only x86, AMD64 and PowerPC are fully supported by
+libhugetlbfs. IA64 and Sparc64 have a working malloc, and SH64
+should also but it has not been tested. IA64, Sparc64, and SH64
+do not support segment remapping at this time.
Kernel prerequisites
--------------------
@@ -261,12 +261,14 @@ to regain some of the performance impact of local-node
allocations on
large NUMA systems. This can still result in poor performance for those
applications which carefully place their threads on particular nodes
(such as by using OpenMP). In that case, thread-local allocation is
-preferred. Users can specify HUGETLB_NO_PREFAULT to prevent the
-prefaulting of hugepages and instead rely on run-time faulting of
-hugepages. NOTE: specifying HUGETLB_NO_PREFAULT on a system where
-hugepages are available to and used by many process can result in some
-applications receving SIGKILL, so its use is not recommended in
-high-availability or production environments.
+preferred so users should select a memory policy that corresponds to
+the run-time behavior of the process' CPU usage. Users can specify
+HUGETLB_NO_PREFAULT to prevent the prefaulting of hugepages and instead
+rely on run-time faulting of hugepages. NOTE: specifying
+HUGETLB_NO_PREFAULT on a system where hugepages are available to and
+used by many process can result in some applications receving SIGKILL,
+so its use is not recommended in high-availability or production
+environments.
By default, the hugepage heap does not shrink. To enable hugepage heap
shrinking, set HUGETLB_MORECORE_SHRINK=yes. NB: We have been seeing some
@@ -401,7 +403,7 @@ huge pages will be used to store the same program data.
The reduce this wastage, libugetlbfs can be instructed to allow
sharing segments between multiple invocations of a program. To do
this, you must set the HUGETLB_SHARE variable must be set for all the
-processes in question. This variable has three possible values:
+processes in question. This variable has two possible values:
anything but 1: the default, indicates no segments should be shared
1: indicates that read-only segments (i.e. the program text,
in most cases) should be shared, read-write segments (data and bss)
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
