Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932405AbZJ3PQc (ORCPT ); Fri, 30 Oct 2009 11:16:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932394AbZJ3PQa (ORCPT ); Fri, 30 Oct 2009 11:16:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59251 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932358AbZJ3PQV (ORCPT ); Fri, 30 Oct 2009 11:16:21 -0400 Date: Fri, 30 Oct 2009 16:15:44 +0100 From: Andrea Arcangeli To: Vedran =?utf-8?B?RnVyYcSN?= Cc: David Rientjes , Hugh Dickins , KAMEZAWA Hiroyuki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, KOSAKI Motohiro , minchan.kim@gmail.com, Andrew Morton Subject: Re: Memory overcommit Message-ID: <20091030151544.GR9640@random.random> References: <4AE846E8.1070303@gmail.com> <4AE9068B.7030504@gmail.com> <4AE97618.6060607@gmail.com> <4AEAEFDD.5060009@gmail.com> <20091030141250.GQ9640@random.random> <4AEAFB08.8050305@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4AEAFB08.8050305@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1954 Lines: 40 On Fri, Oct 30, 2009 at 03:41:12PM +0100, Vedran Furač wrote: > Oh... so this is because apps "reserve" (Committed_AS?) more then they > currently need. They don't actually reserve, they end up "reserving" if overcommit is set to 2 (OVERCOMMIT_NEVER)... Apps aren't reserving, more likely they simply avoid a flood of mmap when a single one is enough to map an huge MAP_PRIVATE region like shared libs that you may only execute partially (this is why total_vm is usually much bigger than real ram mapped by pagetables represented in rss). But those shared libs are 99% pageable and they don't need to stay in swap or ram, so overcommit-as greatly overstimates the actual needs even if shared lib loading wouldn't be 64bit optimized (i.e. large and a single one). > A the time of "malloc: Cannot allocate memory": > > CommitLimit: 3364440 kB > Committed_AS: 3240200 kB > > So probably everything is ok (and free is misleading). Overcommit is > unfortunately necessary if I want to be able to use all my memory. Add more swap. > Btw. http://www.redhat.com/advice/tips/meminfo.html says Committed_AS is > a (gu)estimate. Hope it is a good (not to high) guesstimate. :) It is a guess in the sense to guarantee no ENOMEM it has to take into account the worst possible case, that is all shared lib MAP_PRIVATE mappings are cowed, which is very far from reality. Other than that the overcommitas should exactly match all mmapped possibly writeable space that can only fit in ram+swap, so from that point of view it's not a guessed number (modulo the smp read out of order). The only guess is how much slab, cache and other stuff is freeable, which doesn't provide true perfection to OVERCOMMIT_NEVER. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/