About Transparent Superpages and Non-transparent superapges

[Sebastian Kuzminsky]

On Sep 20, 2013, at 19:09 , Cedric Blancher wrote:

> On 20 September 2013 17:20, Sebastian Kuzminsky <S.Kuzminsky at f5.com> wrote:
>> On Sep 19, 2013, at 22:06 , Patrick Dung wrote:
>> 
>>>> We at Line Rate (now F5) are developing support for 1 Gig superpages on amd64.  We're basing our work on 9.1.0 for now.
>>>> 
>>>> An early preview is available here:
>>>> 
>>>> https://github.com/Seb-LineRate/freebsd/tree/freebsd-9.1.0-1gig-pages-NOT-READY-2
>>> 
>>> That is cool.
>>> 
>>> What type of applications can take advantage of the 1Gb page size?
>>> And is it transparent? Or applications need to be modified?
>> 
>> It's transparent for the kernel: all of UMA and kmem_malloc()/kmem_free() is backed by 1 gig superpages.
>> 
>> It's not transparent for userspace: applications need to pass a new flag to mmap() to get 1 gig pages.
> 
> That may be the wrong approach. What happens if x86 gets more
> huge/largepage sizes like SPARC does (hint: Sign NDA with Intel and
> AMD and get surprised, and then allocate 16 more bits for mmap() if
> you wish to stick with your approach)? For example SPARC64 does 8k,
> 64k, 512k, 4M, 32M, 256M, 2GB and 256GB pages (actual page sizes
> differ from MMU to MMU implementation, and can be probed via pagesize
> -a).
> 
> A much better option would be to follow the Solaris API which has APIs
> to enumerate the available page sizes, and then set it either for
> heap, stack or a given address range (the last one is used to use
> largepages for file I/O via mmap()).

I discussed this API with Alan Cox at the FreeBSD Developers' Summit in Ottawa in May 2013, and he agreed that this was a good place to start.  The main concern he had at the time was that the buddy allocator I implemented in kmem_malloc() might need improvements.

The API you describe sounds more flexible and possibly preferable, and I'm open to discussing it as an enhancement.


-- 
Sebastian Kuzminsky