1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
03 December 2015 -- Yet another mailing list move
librelist seems to be dead or at least broken. I have recieved several
emails directly saying that patches were posted, but they never got
responses and the archives always seem empty. So we are moving the list
again. This from here on out we will be using
libhugetlbfs@googlegroups.com
as our mailing list. Please send patches to this list rather than
creating a pull request.
03 June 2015 -- libhugetlbfs to find new home
As part of the fall out from the recent hijacking various "unmaintained"
projects, I no longer wish to host this (or any other) project at
sourceforge. Effective today, the new official home for libhugetlbfs
code is
https://github.com/libhugetlbfs/libhugetlbfs
The doubling of the name is unfortunate, but I wanted the repo to belong
to the org of the same name so there it is.
Please do not submit pull requests, they will be closed with a redirect
to the mailing list (see below) at best, or ignored completely at worst.
Tarballs of specific releases can still be downloaded using the github
Download ZIP button from the appropriate tag (or branch). The mailing
list will now hosted at librelists and can be found at
libhugetlbfs@librelist.com
For libhugetlbfs usage, see the HOWTO, for what has changed see NEWS,
and for how to work with the project see SubmittingCode
10/03/2006 -- libhugetlbfs-1.0 Released
After roughly one year in development, version 1.0 of libhugetlbfs is here.
It can be downloaded from SourceForge or the OzLabs mirror:
http://sourceforge.net/project/showfiles.php?group_id=156936
http://libhugetlbfs.ozlabs.org/snapshots/
After a series of preview releases, we have tested a huge array of the
supported usage scenarios using benchmarks and real HPC applications.
Usability and reliability have greatly improved. But... due to the
incredible diversity of applications that exist, there is bound to be a few
that will not work correctly.
If using libhugetlbfs makes your application slower:
* Play around with the different combinations of hugetlb malloc and the
two different supported link types to see which combination works best.
* Keep in mind that huge pages are a niche performance tweak and are not
suitable for every type of application. They are specifically known to
hurt performance in certain situations.
If you experience problems:
* You've already read the HOWTO document, but read through it again. It
is full of hints, notes, warnings, and caveats that we have found over
time. This is the best starting point for a quick resolution to your
issue.
* Make sure you have enough huge pages allocated. Even if you think you
have enough, try increasing it to a number you know you will not use.
* Set HUGETLB_VERBOSE=99 and HUGETLB_DEBUG=yes. These options increase
the verbosity of the library and enable extra checking to help diagnose
the problem.
If the above steps do not help, send as much information about the problem
(including all libhugetlbfs debug output) to
libhugetlbfs@googlegroups.com and we'll help out as much as we
can. We will probably ask you to collect things like: straces,
/proc/pid/maps and gdb back traces.
|
