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.0 required=5.0 tests=AWL,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 CBA01BC69 for ; Wed, 14 Nov 2007 13:03:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHZzOkfAXQImh2dsb2JhbACPAAEICik X-IronPort-AV: E=Sophos;i="4.21,415,1188770400"; d="scan'208";a="4437109" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 14 Nov 2007 13:03:28 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lAEC3SPk028778 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 14 Nov 2007 13:03:28 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFZyOkdA6ba5kGdsb2JhbACPAAEBBwIGJAc X-IronPort-AV: E=Sophos;i="4.21,415,1188770400"; d="scan'208";a="19276063" Received: from nf-out-0910.google.com ([64.233.182.185]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 Nov 2007 13:03:27 +0100 Received: by nf-out-0910.google.com with SMTP id g13so150066nfb for ; Wed, 14 Nov 2007 04:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cPEKJkYLupFl/XvNqGHDf55PJc1nN3Jmx+puBCs75jQ=; b=fxwc0j3UjnxSWj3sFcGJFAsSOLkRiRfvefl5VQNotw6eEhH/f11NZyiQSg6M7VvFoB/65RREILhGa9WHvZndOhWfsQM+6MyPqDC8Jlco4MKbv08OvxR56EFfcHibDd1S4YwVRPqO6d4hrqIcMYeKqoJaQiU0D/IuhBz4D8C4Jy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nyy7c7JGaTORJuwgZEKgBAPpARdSH2NyAERP6mjMj9bXncLN5Ng70uTvJz8mXwru8e6lthr5yjnWWHMp1doR04eNx2598H5f8ahbvX6ktAXwx0fYmcPvW4qv+QCqYUnFrIrhWoPfTamA2eZm7rOpo8flbhH/UOlb5j9ngRrMI2A= Received: by 10.78.138.6 with SMTP id l6mr7884671hud.1195041806647; Wed, 14 Nov 2007 04:03:26 -0800 (PST) Received: by 10.78.173.7 with HTTP; Wed, 14 Nov 2007 04:03:26 -0800 (PST) Message-ID: <8ef825670711140403m464c01detff5537abb2211946@mail.gmail.com> Date: Wed, 14 Nov 2007 15:03:26 +0300 From: "Vladimir Shabanov" To: caml-list@inria.fr Subject: Re: [Caml-list] OCaml runtime using too much memory in 64-bit Linux In-Reply-To: <200711140520.46016.romain.beauxis@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4731F5D1.2070405@janestcapital.com> <1194459622.15728.94.camel@localhost.localdomain> <47320E10.1050307@janestcapital.com> <200711140520.46016.romain.beauxis@gmail.com> X-Miltered: at discorde with ID 473AE410.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 runtime:01 bytecode:01 bytecode:01 vals:01 960:98 960:98 1440:98 1920:98 1440:98 stack:01 heap:01 heap:01 caml-list:01 blank:97 2007/11/14, Romain Beauxis : > Following Sam's answer on similar issue with our application, here are two > compared outputs for the same informations: > > -- On i386: > 5:13 toots@selassie ~% OCAMLRUNPARAM="v=12" liquidsoap 'output.dummy(blank())' > 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 > > -- On amd64: > 5:12 toots@ras-macintosh ~/sources/svn/savonet/trunk/liquidsoap/src% > OCAMLRUNPARAM="v=12" ./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 > quite enourmeous, compared to similar values for i386. I also have problems with my application on amd64. The difference is that I have additional memory allocated only in bytecode executable. native amd64: $ OCAMLRUNPARAM="v=12" ./_build/game.opt Growing heap to 960k bytes Growing page table to 72391 entries ... (program output stripped) Growing heap to 1440k bytes Growing page table to 90522 entries ... bytecode amd64: $ OCAMLRUNPARAM="v=12" ./_build/game Initial stack limit: 8192k bytes Growing gray_vals to 32k bytes Growing heap to 960k bytes Growing page table to 141518746 entries ... Growing heap to 1440k bytes ... It gives me 80--300MB of additional memory allocated (virt & res). Interestingly enough the number of page table entries is different from run to run (hence the non-constant additional memory size). In native executable page table entries count is constant.