Date: Mon, 23 Sep 2013 17:16:06 +0000 From: Sebastian Kuzminsky <S.Kuzminsky@F5.com> To: Cedric Blancher <cedric.blancher@gmail.com> Cc: Sebastian Kuzminsky <S.Kuzminsky@F5.com>, Patrick Dung <patrick_dkt@yahoo.com.hk>, "ivoras@freebsd.org" <ivoras@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: About Transparent Superpages and Non-transparent superapges Message-ID: <D8C2FE3C-B077-4678-ABEA-B6E286DCFA50@f5.com> In-Reply-To: <CALXu0UeA14y8Riy1ji777-gvW5CJb9soRoxg7fzB6kF1Nn=Cbg@mail.gmail.com> References: <mailman.2681.1379448875.363.freebsd-hackers@freebsd.org> <1379520488.49964.YahooMailNeo@web193502.mail.sg3.yahoo.com> <22E7E628-E997-4B64-B229-92E425D85084@f5.com> <1379649991.82562.YahooMailNeo@web193502.mail.sg3.yahoo.com> <B3A1DB16-7919-4BFA-893C-5E8502F16C17@f5.com> <CALXu0UeA14y8Riy1ji777-gvW5CJb9soRoxg7fzB6kF1Nn=Cbg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 20, 2013, at 19:09 , Cedric Blancher wrote: > On 20 September 2013 17:20, Sebastian Kuzminsky <S.Kuzminsky@f5.com> wrot= e: >> On Sep 19, 2013, at 22:06 , Patrick Dung wrote: >>=20 >>>> We at Line Rate (now F5) are developing support for 1 Gig superpages o= n amd64. We're basing our work on 9.1.0 for now. >>>>=20 >>>> An early preview is available here: >>>>=20 >>>> https://github.com/Seb-LineRate/freebsd/tree/freebsd-9.1.0-1gig-pages-= NOT-READY-2 >>>=20 >>> That is cool. >>>=20 >>> What type of applications can take advantage of the 1Gb page size? >>> And is it transparent? Or applications need to be modified? >>=20 >> It's transparent for the kernel: all of UMA and kmem_malloc()/kmem_free(= ) is backed by 1 gig superpages. >>=20 >> It's not transparent for userspace: applications need to pass a new flag= to mmap() to get 1 gig pages. >=20 > 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). >=20 > 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 Ott= awa in May 2013, and he agreed that this was a good place to start. The ma= in 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. --=20 Sebastian Kuzminsky
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8C2FE3C-B077-4678-ABEA-B6E286DCFA50>