On Sep 20, 2013, at 19:09 , Cedric Blancher wrote: > On 20 September 2013 17:20, Sebastian Kuzminsky <s.kuzmin...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
