peter.schuller at infidyne.com
Thu Jan 3 13:00:24 PST 2008
> 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
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 at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080103/1864c08d/attachment.pgp
More information about the freebsd-current