Re: ten thousand small processes

From: Jeff Roberson (jroberson_at_chesapeake.net)
Date: 06/24/03

  • Next message: Jeff Roberson: "Re: ten thousand small processes" 
    Date: Mon, 23 Jun 2003 19:27:22 -0400 (EDT)
To: "D. J. Bernstein" <djb@cr.yp.to>

    On 21 Jun 2003, D. J. Bernstein wrote:

    > 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.)

    Even small programs need page tables. On x86 unix you need at least
    pages for page tables for any process, if I'm counting correctly. One for
    the page directory, one page table for text, data, bss, and the guard
    page, and one page table page for stack.

    32 of those 'pages of VM' are your initial stack size. They don't really
    consume any resources other than preventing anyone else from allocating
    overlapping pages. It's just the initial upper limit on the stack map
    which is allowed to grow. I haven't looked closely enough to find out
    what the other 7 might be.

    There is an obstacle to having a small program fit into one page.
    Actually, a significant one. First of all, you need protections on
    different sections of the actual executable image. Text must be read only
    since it is shared. Data is read write and bss is read-write. BSS is a
    pseudo section and not actually mapped from the file. Text and data both
    can be paged in from the binary in a demand paged system such as freebsd.
    Data can not be written out to its backing object and neither can text.
    Text can be shared while data changes are private and so the two must be
    placed in seperate pages. This topic is explored quite well in any modern
    operating systems book. I suggest you pick up "The Design and
    Implementation of the 4.4BSD Operating System". It is a little out dated
    but provides a good introduction to these topics. I really didn't do them
    justice with this paragraph.

    If demand paging, shared libraries, and the like are not suited for your
    problem perhaps you should look at an embedded operating system? Or DOS
    even.

    Cheers,
    Jeff

    >
    > 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@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"
    >

    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"

  • Next message: Jeff Roberson: "Re: ten thousand small processes"

    Relevant Pages

    • Re: Static allocation failure?
      ... adjust the heap size. ... the BSS with memory from the heap, if I set my heap size way larger ... The compiler generates a series of fragments which the linker then ... How big does the stack need to be? ...
      (comp.arch.embedded)
    • Re: ten thousand small processes
      ... On Mon, 23 Jun 2003, Jeff Roberson wrote: ... Data is read write and bss is read-write. ... > can be paged in from the binary in a demand paged system such as freebsd. ... > Implementation of the 4.4BSD Operating System". ...
      (freebsd-performance)
    • Re: variable allocated from stack/bss ??
      ... int main{ ... allocated from bss the default value would be 0 ... Local variables are stored on the stack. ... qualification to give meaningful answers. ...
      (comp.lang.c)
    • Re: variable allocated from stack/bss ??
      ... int main{ ... allocated from bss the default value would be 0 ... Local variables are stored on the stack. ... qualification to give meaningful answers. ...
      (comp.lang.c)
    • Re: execve() and heap memory
      ... bss, and stack of the calling process are overwritten by ... This is typically placed in memory above the 'text' (or at ... literals) in the text segment. ... Stack instructions in the 'text', ...
      (comp.unix.programmer)