Date: Thu, 2 Dec 2010 13:14:20 -0800 From: Artem Belevich <fbsdlist@src.cx> To: Andrew Duane <aduane@juniper.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Question about process rlimits Message-ID: <AANLkTi=g_wCn2UK8afB0srfM%2B_y8gNLCKQKDRxrNUdSg@mail.gmail.com> In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AE907A1E0703@EMBX01-WF.jnpr.net> References: <AC6674AB7BC78549BB231821ABF7A9AE907A1E0703@EMBX01-WF.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Thu, Dec 2, 2010 at 12:51 PM, Andrew Duane <aduane@juniper.net> wrote: > > I've been poking at some bugs we have around pushing user memory to/past = the limits of our box, and decided to try seeing what happens on a stock Fr= eeBSD system (7.1 in this case). > > Basically I have a program that mallocs big memory chunks and zeros them = to consume both physical and virtual memory. I had expected the program to = stop malloc'ing when brk() reaches the process' RLIMIT_DATA (512MB cur and = max). It didn't. It happily malloc'd many gigabytes of memory until I stopp= ed it. > > On our 6.2 based product boxes, RLIMIT_DATA correctly stops the malloc fr= om continuing, just like the manuals say. > > Am I missing something? Perhaps that malloc has two ways of grabbing memory from system -- sbrk() and mmap() and they are subject to different limits. I believe these days malloc is allowed to use both but prefers mmap which would explain why RLIMIT_DATA didn't have much effect. Try forcing malloc to use sbrk only via MALLOC_OPTIONS=3DDm (not sure if that's correct way to specify my intent, though). --Artem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=g_wCn2UK8afB0srfM%2B_y8gNLCKQKDRxrNUdSg>