From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 2F338BC69 for ; Wed, 14 Nov 2007 05:21:01 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHoGOkfAXQInh2dsb2JhbACOfwEICik X-IronPort-AV: E=Sophos;i="4.21,413,1188770400"; d="scan'208";a="4409771" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 05:21:00 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id lAE4L0vI031172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 14 Nov 2007 05:21:00 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHoGOkdYvxGE/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.21,413,1188770400"; d="scan'208";a="5767895" Received: from www.rastageeks.org (HELO mail.rastageeks.org) ([88.191.17.132]) by mail3-smtp-sop.national.inria.fr with ESMTP; 14 Nov 2007 05:20:48 +0100 Received: from [192.168.0.2] (rob92-9-88-161-115-205.fbx.proxad.net [88.161.115.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rastageeks.org (Postfix) with ESMTP id C567F9C4F3 for ; Wed, 14 Nov 2007 05:20:47 +0100 (CET) From: Romain Beauxis To: caml-list@inria.fr Subject: Re: [Caml-list] OCaml runtime using too much memory in 64-bit Linux Date: Wed, 14 Nov 2007 05:20:45 +0100 User-Agent: KMail/1.9.7 References: <4731F5D1.2070405@janestcapital.com> <1194459622.15728.94.camel@localhost.localdomain> <47320E10.1050307@janestcapital.com> In-Reply-To: <47320E10.1050307@janestcapital.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200711140520.46016.romain.beauxis@gmail.com> X-Miltered: at concorde with ID 473A77AC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 runtime:01 gerd:01 stolpmann:01 ocaml:01 runtime:01 o'caml:01 960:98 1440:98 1920:98 960:98 1440:98 1920:98 wrote:01 heap:01 Hi all ! Le Wednesday 07 November 2007 20:12:16 Adam Chlipala, vous avez =E9crit=A0: > Gerd Stolpmann wrote: > > Am Mittwoch, den 07.11.2007, 12:28 -0500 schrieb Adam Chlipala: > >> I've encountered a problem where certain OCaml programs use orders of > >> magnitude more RAM when compiled/run in 64-bit Linux instead of 32-bit > >> Linux. Some investigation led to the conclusion that the difference h= as > >> to do with the size of OCaml page tables. (Here I mean the page tables > >> maintained by the OCaml runtime system, not any OS stuff.) > >> > >> ... > > > > We are using O'Caml on 64 bit Linux, and aren't aware of such problems. > > > > Did you observe a debug GC message that proves it? 200 MB means that an > > address space of 200M * 4K =3D 8E is covered. > > Here's one run, cut off after allocation seems to settle down: > > OCAMLRUNPARAM=3D"v=3D12" ./program_name.exe > Growing heap to 960k bytes > Growing page table to 204151332 entries > Growing heap to 1440k bytes > Growing heap to 1920k bytes =46ollowing Sam's answer on similar issue with our application, here are tw= o=20 compared outputs for the same informations: =2D- On i386: 5:13 toots@selassie ~% OCAMLRUNPARAM=3D"v=3D12" liquidsoap 'output.dummy(bl= ank())' Growing heap to 480k bytes Growing page table to 2648 entries Growing heap to 720k bytes Growing page table to 2710 entries Growing heap to 960k bytes Growing page table to 2815 entries =2D- On amd64: 5:12 toots@ras-macintosh ~/sources/svn/savonet/trunk/liquidsoap/src%=20 OCAMLRUNPARAM=3D"v=3D12" ./liquidsoap 'output.dummy(blank())' Growing heap to 960k bytes Growing page table to 104640820 entries Growing heap to 1440k bytes Growing heap to 1920k bytes It seems that the "Growing page table to 104640820 entries" in amd64's log = is=20 quite enourmeous, compared to similar values for i386. Sorry, I can't debug more, I'm not expert at all on this topic. However, I'll be glad to dig more if indicated what to do.. Romain