From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 21:00:24 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E1416A46B for ; Thu, 3 Jan 2008 21:00:24 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id DCB1D13C4DB for ; Thu, 3 Jan 2008 21:00:23 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 3B1D4755CE; Thu, 3 Jan 2008 22:00:22 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Thu, 3 Jan 2008 22:00:16 +0100 User-Agent: KMail/1.9.7 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> In-Reply-To: <863ateemw2.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5171116.mP4KcXQ2ne"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200801032200.25650.peter.schuller@infidyne.com> Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 21:00:24 -0000 --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 ' 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--