This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Failed to load latest commit information.
Latest commit message
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 firstname.lastname@example.org 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 email@example.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 firstname.lastname@example.org 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.
No packages published