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=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 0EDA7BC6B for ; Thu, 8 Nov 2007 13:56:43 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAA6WMkdQwu2u/2dsb2JhbACBWw X-IronPort-AV: E=Sophos;i="4.21,389,1188770400"; d="scan'208";a="4028865" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 08 Nov 2007 13:56:42 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id lA8CugHu010279 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 8 Nov 2007 13:56:42 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAA6WMkdQwu2u/2dsb2JhbACBWw X-IronPort-AV: E=Sophos;i="4.21,389,1188770400"; d="scan'208";a="4028864" Received: from 80-194-237-174.cable.ubr04.camd.blueyonder.co.uk (HELO babasse.is-a-geek.org) ([80.194.237.174]) by mail2-smtp-roc.national.inria.fr with ESMTP; 08 Nov 2007 13:56:42 +0100 Received: from localhost ([127.0.0.1] helo=babasse.is-a-geek.org) by babasse.is-a-geek.org with esmtp (Exim 4.67) (envelope-from ) id 1Iq6w4-00031b-0Q; Thu, 08 Nov 2007 12:56:40 +0000 Message-ID: <47330787.6050305@ens-lyon.org> Date: Thu, 08 Nov 2007 12:56:39 +0000 From: Samuel Mimram User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: caml-list@inria.fr Cc: Adam Chlipala , Gerd Stolpmann Subject: Re: [Caml-list] OCaml runtime using too much memory in 64-bit Linux References: <4731F5D1.2070405@janestcapital.com> <1194459622.15728.94.camel@localhost.localdomain> <47320E10.1050307@janestcapital.com> In-Reply-To: <47320E10.1050307@janestcapital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4733078A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ens-lyon:01 ocaml:01 runtime:01 gerd:01 stolpmann:01 ocaml:01 runtime:01 o'caml:01 960:98 1440:98 1920:98 4540:98 960:98 1440:98 wrote:01 Hi, Adam Chlipala wrote: > 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 has 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 = 8E is covered. We are observing the same memory consumption problems with liquidsoap[1]. On 32-bits machines ps says that it takes around 50M / 10M of VSZ / RSS whereas on 64-bits machines it takes 200M / 100M which is much much bigger! Here is the initial stack an heap allocation on 32-bits archs: % OCAMLRUNPARAM="v=12" ./liquidsoap 'output.dummy(blank())' Growing heap to 480k bytes Growing page table to 3040 entries Growing heap to 720k bytes Growing page table to 3354 entries Growing heap to 960k bytes Growing page table to 3532 entries Growing heap to 1200k bytes Growing page table to 4251 entries Growing heap to 1440k bytes Growing page table to 4416 entries Growing heap to 1680k bytes Growing page table to 4478 entries Growing heap to 1920k bytes Growing page table to 4540 entries And on 64-bits archs: $ OCAMLRUNPARAM="v=12" ./liquidsoap 'output.dummy(blank())' Growing heap to 960k bytes Growing page table to 118256149 entries Growing heap to 1440k bytes I'm not sure I fully understand what these figures are. Is it expected for the page table to be bigger with that many orders of magnitude on 64-bits archs? Thanks! Samuel. [1] http://savonet.sf.net/