Date: Thu, 3 Jan 2008 22:00:16 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: freebsd-current@freebsd.org Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no>, Jason Evans <jasone@freebsd.org> Subject: Re: sbrk(2) broken Message-ID: <200801032200.25650.peter.schuller@infidyne.com> In-Reply-To: <863ateemw2.fsf@ds4.des.no> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > The real question is why we would revert perfectly good code (jemalloc) > from using a modern interface to using one that has been obsolete for > twenty years, and marked as such in the man page for seven years. Also, may I humbly inject a user centric view here - it is pretty annoying to be limited to 500 MB of mallocable memory on 32 bit machines when you expect 3 GB to be usable (with 1 GB mapped to the kernel). I scratched my head for a long time as to why I was getting out of memory errors in spite of carefully setting resource limits and ensuring virtual memory was available; at some later point in time I discovered the hard-coded distinction between sbrk():able and mmap():able memory. I am not sure what I was supposed to find this in the documentation (I found it by chance Googling). If sbrk() is indeed to be used by the default malloc, one definitely user visible annoyance will be the 500 MB limit. At least with mmap() that will be 2.5 GB, unless I am misstaken, which is much closer to what one might expect and thus less likely to cause problems in the common case. Changing maxdsize to be > 500 MB is probably bad too, from a user centric view, since you don't want to cause the equivalent problems for programs that do not use malloc(), but are indeed coded with "modern virtual memory" (as the man page calls it) in mind. Better to leave this problem to those programs that use sbrk() directly. Another consequence is that if the sysadmin really wants a maximum amount of mmap():able memory, the maxdsize can presumably be lowered quite heftily without affecting the vast majority of applications. With malloc() use of sbrk() however, you will have mutual exclusivity between the common case (malloc() users), and special purpose applications that *do* try to be nice, modern and use mmap() instead of sbrk(). With mutual exclusivity between malloc() users and sbrk() users, at least you can kinda blame the sbrk() user for using an obsolete interface. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHfUzpDNor2+l1i30RAlbsAJ909pEzkhUjnXZvBYShQfUQx6glgwCePwhB 3Czbf4ypqFjtYlq4n8yi9u8= =Cp8o -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801032200.25650.peter.schuller>