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
--nextPart5171116.mP4KcXQ2ne Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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=20 be limited to 500 MB of mallocable memory on 32 bit machines when you expec= t=20 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=20 errors in spite of carefully setting resource limits and ensuring virtual=20 memory was available; at some later point in time I discovered the hard-cod= ed=20 distinction between sbrk():able and mmap():able memory. I am not sure what = I=20 was supposed to find this in the documentation (I found it by chance=20 Googling). If sbrk() is indeed to be used by the default malloc, one definitely user=20 visible annoyance will be the 500 MB limit. At least with mmap() that will = be=20 2.5 GB, unless I am misstaken, which is much closer to what one might expec= t=20 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=20 view, since you don't want to cause the equivalent problems for programs th= at=20 do not use malloc(), but are indeed coded with "modern virtual memory" (as= =20 the man page calls it) in mind. Better to leave this problem to those=20 programs that use sbrk() directly. Another consequence is that if the sysadmin really wants a maximum amount o= f=20 mmap():able memory, the maxdsize can presumably be lowered quite heftily=20 without affecting the vast majority of applications. With malloc() use of=20 sbrk() however, you will have mutual exclusivity between the common case=20 (malloc() users), and special purpose applications that *do* try to be nice= ,=20 modern and use mmap() instead of sbrk(). With mutual exclusivity between=20 malloc() users and sbrk() users, at least you can kinda blame the sbrk() us= er=20 for using an obsolete interface. =2D-=20 / 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 --nextPart5171116.mP4KcXQ2ne Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHfUzpDNor2+l1i30RAlbsAJ909pEzkhUjnXZvBYShQfUQx6glgwCePwhB 3Czbf4ypqFjtYlq4n8yi9u8= =Cp8o -----END PGP SIGNATURE----- --nextPart5171116.mP4KcXQ2ne--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801032200.25650.peter.schuller>