ten thousand small processes
D. J. Bernstein
djb at cr.yp.to
Sun Jun 22 19:59:33 PDT 2003
alloca() is inadequate. Memory allocation doesn't always follow a stack
pattern. I certainly can't predict memory use at the top of main().
sbrk() is dangerous. Suppose a system call that I'm using turns into a
library routine that calls malloc()---this has happened to poll() and to
socket(), so it could happen again. Suppose the malloc() implementor
assumes that the memory he gets from sbrk() is contiguous. Kaboom.
(If the sbrk() manual page said that this was the malloc() implementor's
fault, maybe I'd risk it. But the manual page clearly says I shouldn't.
``Duh, why would anyone want to use more than one allocator library?'')
Even if I get malloc() under control somehow, I'll still have 30-odd
unexplained VM pages going down the tubes. Is this, in fact, the stack?
Why doesn't it start at 4K?
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
More information about the freebsd-performance