From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q09EVvxS006733 for ; Mon, 9 Jan 2012 15:31:57 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAj6Ck9QRFuw/2dsb2JhbABErFKBBYFyAQEDAgwmAUYQCxgcEhQoIYgPBrYpg32BGIYZYwSVCJI6 X-IronPort-AV: E=Sophos;i="4.71,480,1320620400"; d="scan'208";a="138430842" Received: from furbychan.cocan.org ([80.68.91.176]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 09 Jan 2012 15:31:43 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.72) (envelope-from ) id 1RkGGF-00028Q-6I; Mon, 09 Jan 2012 14:31:43 +0000 Date: Mon, 9 Jan 2012 14:31:43 +0000 From: "Richard W.M. Jones" To: =?iso-8859-1?B?VPZy9ms=?= Edwin Cc: caml-list@inria.fr Message-ID: <20120109143143.GA31093@annexia.org> References: <96F225D0-B458-4E25-BE34-3976989984B2@ezabel.com> <20120101124454.GA12851@annexia.org> <012932EC-860F-4A40-98D1-E4B6EC123927@ezabel.com> <20120108184505.GA30498@annexia.org> <20120108190049.GB30498@annexia.org> <4F0A19CD.2030906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F0A19CD.2030906@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] Understanding usage by the runtime On Mon, Jan 09, 2012 at 12:33:49AM +0200, Török Edwin wrote: > On 01/08/2012 09:00 PM, Richard W.M. Jones wrote: > >Probably the OCaml GC should be setting madvise hints anyway. > > It should mmap()/munmap() instead of malloc/realloc/free in that > case, right? Which probably wouldn't be a bad idea, as you don't > get the fragmentation issues as much as you do with malloc. Simply ensuring the mallocs are aligned to pages (ie using posix_memalign) should be sufficient to allow madvise to be used. As you say it may be better to use mmap for other reasons. > >While we're at it, the GC may be able to cooperate better with the > >new(-ish) Transparent Hugepages feature of Linux. > > Does it suffice to allocate the major heap in 2MB increments to take advantage of that? Yes. Check this file: /sys/kernel/mm/transparent_hugepage/enabled If it says: [always] advise never then any contiguous anonymous (ie. malloc) virtual memory mapping which is 2MB or larger and aligned to 2MB is a candidate for being turned into THPs. It's thus very easy to use and most processes get it for free. Certain kernel operations cause huge pages to be split. Things like creating a futex in a page. So you have to be a bit careful. This talk by my colleague explains THP (in the context of KVM, but applies to any process): http://www.linux-kvm.org/wiki/images/9/9e/2010-forum-thp.pdf Rich. -- Richard Jones Red Hat