From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,be7fa91648ac3f12 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news2.google.com!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: Duncan Sands Newsgroups: comp.lang.ada Subject: Re: Large arrays (again), problem case for GNAT Date: Thu, 14 Apr 2005 09:34:10 +0200 Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: melchior.cuivre.fr.eu.org 1113464080 17493 212.85.156.195 (14 Apr 2005 07:34:40 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Thu, 14 Apr 2005 07:34:40 +0000 (UTC) Cc: comp.lang.ada@ada-france.org To: "Alexander E. Kopilovich" Return-Path: In-Reply-To: X-Mailer: Evolution 2.2.1.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:10450 Date: 2005-04-14T09:34:10+02:00 > So, what is the meaning of malloc call with this approach? In which court > (somewhere in Linux or outside) I should defend my right to use the memory, > which I legally requested by malloc, was granted, and then deprived of it? Hi Alexander, I'd be interested to see the standard that stipulates that the default linux behavior is illegal. Anyway, you can choose the strategy by writing to /proc/sys/vm/overcommit_memory. Here is what the documentation for 2.6 kernels says: > overcommit_memory: > > This value contains a flag that enables memory overcommitment. > > When this flag is 0, the kernel attempts to estimate the amount > of free memory left when userspace requests more memory. > > When this flag is 1, the kernel pretends there is always enough > memory until it actually runs out. > > When this flag is 2, the kernel uses a "never overcommit" > policy that attempts to prevent any overcommit of memory. > > This feature can be very useful because there are a lot of > programs that malloc() huge amounts of memory "just-in-case" > and don't use much of it. > > The default value is 0. > > See Documentation/vm/overcommit-accounting and > security/commoncap.c::cap_vm_enough_memory() for more information.