> The real question is why we would revert perfectly good code (jemalloc)
quoted text
> 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