Hugepages support for FreeBSD

[Scott Bennett]

     On Wed, 27 Aug 2014 14:24:18 -0400 Lowell Gilbert
<freebsd-questions-local at be-well.ilk.org> wrote:
>Abdul Rasheed Shaik <ABDUL.RASHEED at LNTTECHSERVICES.COM> writes:
>
>> Anybody please let me know is there any way to have hugepages support in FreeBSD?
>> This is some thing like we have in Linux.
>
>"Superpage" support has been present in FreeBSD for years. 

     Yes, since 7.2 and, IIRC, 8.0 or maybe 8.1.

>If your system has the vm.pmap.pg_ps_enabled sysctl set,

     In 7.2 and 8.0 (or whichever 8.x first supported it), the sysctl
variable was set to 0 (disabled) by default, so if you wanted it active,
you had to set it in /boot/loader.conf (or by hand at the boot loader's
prompt).  Since 7.3 and 8.whatever, though, it has been enabled by
default.

>you already have it. As you'd expect, it isn't supported
>on all platforms, but if your architecture has decent 
>memory management hardware, it should be set.

     It's definitely supported on i386 and amd64, and I seem to recall
that ia64 support was added last year.  powerpc (and, I assume, powerpc64)
will never have it because the hardware doesn't support mixed page sizes.
I don't know about sparc or sparc64.  The architecture on which the
Navarro et al. algorithm was first tried was alpha, which appears to have
been dropped entirely by the FreeBSD project sometime in the last few
years (I wasn't paying attention when it happened), but it was just an
experimental implementation by researchers outside of the FreeBSD project.
     What I have been unable to find out by asking on this list is exactly
how *much* of that algorithm has been implemented in its officially released
version.  Specifically, I don't know whether the implementation now supports
more than two page sizes or whether idle threads can migrate misplaced base
pages into their proper page frames in reservations to help fully populate
those reservations.
>
>The API isn't exactly the same as on Linux.
>
     Which is to say that there is no API needed because the algorithm is
fully automated, i.e., if it's turned on at kernel initialization, then it
just works all the time.
     However, mmap(2) now has a MAP_ALIGNED_SUPER flag available that may
help when initially allocating a large amount of memory, but may also cause
mmap() to fail if a reservation cannot be made at the time mmap() is called.
I don't know when this flag was first supported, but I couldn't find anything
like it in 7.x when I looked for it.  In actual practice, I suspect that this
flag rarely makes much difference because the basic algorithm already tries
to create a reservation for a new page allocation that doesn't fall within
an existing reservation's frames.
     In 7.3, getpagesizes(3) was added to FreeBSD.  Although getpagesizes(3)
may provide interesting information, I'm not sure just what real value it
has for the performance of a running program, given that userland programs
have no direct control over the Navarro et al. method.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************