From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 23 17:16:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF913A54; Mon, 23 Sep 2013 17:16:13 +0000 (UTC) (envelope-from S.Kuzminsky@F5.com) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 763112BCC; Mon, 23 Sep 2013 17:16:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.90,963,1371081600"; d="scan'208";a="82507357" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 23 Sep 2013 17:16:06 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Mon, 23 Sep 2013 10:16:06 -0700 From: Sebastian Kuzminsky To: Cedric Blancher Subject: Re: About Transparent Superpages and Non-transparent superapges Thread-Topic: About Transparent Superpages and Non-transparent superapges Thread-Index: AQHOtIlQ/xFJtaAUVEqnjcRRWECf45nN+7CAgAB+KYCAALxWAIAApIIAgAQywIA= Date: Mon, 23 Sep 2013 17:16:06 +0000 Message-ID: References: <1379520488.49964.YahooMailNeo@web193502.mail.sg3.yahoo.com> <22E7E628-E997-4B64-B229-92E425D85084@f5.com> <1379649991.82562.YahooMailNeo@web193502.mail.sg3.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.236] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sebastian Kuzminsky , Patrick Dung , "ivoras@freebsd.org" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:16:13 -0000 On Sep 20, 2013, at 19:09 , Cedric Blancher wrote: > On 20 September 2013 17:20, Sebastian Kuzminsky 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