ten thousand small processes

Michael E. Conlen meconlen at obfuscated.net
Sun Jun 22 00:50:35 PDT 2003

If your going to get this serious about your memory management, couldn't you
just brk yourself and manage it your self? You seem to know exactly what
your looking for and expect a specific result. I wouldn't recommend it to
most, but you seem to know what your doing.

Michael Conlen

-----Original Message-----
From: owner-freebsd-performance at freebsd.org
[mailto:owner-freebsd-performance at freebsd.org]On Behalf Of D. J.
Sent: Saturday, June 21, 2003 2:58 PM
To: freebsd-performance at freebsd.org
Subject: ten thousand small processes

FreeBSD 4.8. Test program: malloc(360); malloc(80); malloc(180);
malloc(16); malloc(440); sleep(10); _exit(0). Compile statically.

The program ends up with 44KB RSS. Where is all that DRAM going? The
program also ends up with 168KB VSZ. Where is all that VM going?

I don't care much about the 3-page text segment. But I do care about the
39 extra pages of VM, and the 8 extra pages of DRAM. There's no obstacle
to having a small program fit into _one_ page per process; two or three
can be excused, but 39 is absurd. (Yes, I know that Solaris is worse.)

At least 2 pages appear to be wasted by exit(), because it brings in a
chunk of stdio, which uses 84 bytes of data and 316 bytes of bss. The
libc implementors clearly don't care about 316 bytes of memory, so why
don't they make those 316 bytes static? Why doesn't the compiler
automatically merge some bss into data when that saves a page? Why can't
I omit exit(), manually or automatically, when it's unreachable?

Furthermore, malloc() appears to chew up a whole new page of DRAM for
each allocation, plus another page---is this counted in VSZ?---for an
anonymous mmap. Would it really be that difficult to fit 1076 bytes of
requested memory into the 3000-odd bytes available at the end of bss?

I sure hope that there's some better explanation for the remaining 32
pages than ``Well, we decided to allocate 131072 bytes of memory for the
stack,'' especially when I'm hard-limiting the stack to 4K before exec.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
freebsd-performance at freebsd.org mailing list
To unsubscribe, send any mail to
"freebsd-performance-unsubscribe at freebsd.org"

More information about the freebsd-performance mailing list