Date: Fri, 04 Jan 2008 11:55:22 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: "Igor Mozolevsky" <igor@hybrid-lab.co.uk> Cc: freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org>, Jason Evans <jasone@freebsd.org> Subject: Re: sbrk(2) broken Message-ID: <86bq81c12d.fsf@ds4.des.no> In-Reply-To: <a2b6592c0801040241l598ea9b7h57ad6889a1eccd3@mail.gmail.com> (Igor Mozolevsky's message of "Fri\, 4 Jan 2008 10\:41\:17 %2B0000") References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <a2b6592c0801040241l598ea9b7h57ad6889a1eccd3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Igor Mozolevsky" <igor@hybrid-lab.co.uk> writes: > Robert Watson <rwatson@freebsd.org> writes: > > To be clear, in the new world order, instead of getting NULL > > back from malloc(3), SIGKILL is delivered to large processes. > Huh??? Again, huh??? For the same reason as it has for the last 20 years or so: memory overcommit, which means that malloc() allocates address space, not memory. Actual memory is allocated on-demand when the address space is used (read from or written to). If there is no RAM left and none can be freed by swapping out, the process gets killed. The process that gets killed is not necessarily the memory hog, it is merely the process that is unlucky enough to touch a new page at the wrong moment, i.e. when all RAM and swap is exhausted *or* everything in RAM is wired down and unswappable. Of course, if you're afraid of memory overcommit and you know in advance how much memory you need, you can simply allocate a sufficient amount of address space at startup and touch it all. This way, you will either be killed right away, or be guaranteed to have sufficient memory for the rest of your (process) lifetime. Alternatively, do what Varnish does: create a large file, mmap it, and allocate everything you need from that area, so you have your own private swap space. Just make sure to actually allocate the disk space you need (by filling the file with zeroes, or at the minimum writing a zero to the file every sb.st_blksize bytes, preferably sequentially to avoid excessive fragmentation) or you may run into the same problem as with malloc() if the disk fills up while your backing file is still sparse. The ability to specify a backing file to use instead of anonymous mappings would be a cool addition to jemalloc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86bq81c12d.fsf>