From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q08N2iEa004253 for ; Mon, 9 Jan 2012 00:02:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFcfCk9QRFuw/2dsb2JhbABCrESBBYFyAQEEAToxDhALGBwSFCg0GgGHXwK0d4UVg2KCN2MElQiSOg X-IronPort-AV: E=Sophos;i="4.71,476,1320620400"; d="scan'208";a="126026088" Received: from furbychan.cocan.org ([80.68.91.176]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 09 Jan 2012 00:02:39 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.72) (envelope-from ) id 1Rk1l8-00008l-6A; Sun, 08 Jan 2012 23:02:38 +0000 Date: Sun, 8 Jan 2012 23:02:38 +0000 From: "Richard W.M. Jones" To: orbitz@ezabel.com Cc: david.baelde@ens-lyon.org, Caml List Message-ID: <20120108230238.GB23941@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] Understanding usage by the runtime On Sun, Jan 08, 2012 at 05:50:40PM -0500, orbitz@ezabel.com wrote: > Isn't the goal of compaction to keep all of these blocks of memory > as close as possible? I should have noted the fragmentation of my > heap after compaction, but it seems unlikely that my < 1meg of actual > data could be fragmented across 400megs worth of chunks. I might not have been clear: memory can only be given back to the OS at the C / malloc allocator level. OCaml compaction has nothing to do with this because C allocations (and data structures used by malloc itself) cannot ever be moved. However you can get a clearer picture if you look at /proc//maps or smaps and also if you have a debugging malloc implementation. > > Here's the news: the OS doesn't need you to give back > > memory. Because of virtual memory and swap, the OS will quite happily > > take back your memory whenever it wants without asking you. > > For most cases this is true, however in my case (which is not the > usual case), my OS has no swap. We actually prefer things to fail > than to be swapped because we are doing computations could take months > if we get into a swapping situation. I'm no linux expert so our > solution is to not have swap and to keep our VMs light when it comes > to I/O. Perhaps this is a poor solution but it does change things for > us. Sure, this is a perfectly valid case, we have many customers who use RHEL like this. Rich. -- Richard Jones Red Hat