Re: ten thousand small processes

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

  • Next message: D. J. Bernstein: "Re: ten thousand small processes" 
    Date: Tue, 24 Jun 2003 20:45:24 -0400 (EDT)
To: "D. J. Bernstein" <djb@cr.yp.to>

    I understand you have some history with the project. As such I believe
    you deserve a more thorough answer. More replies inline.

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

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

    poll() does not call malloc in libc or libc_r. Socket only calls malloc()
    in libc_r. libthr does not call malloc in either case. I'm not sure
    about libkse. Could you clarify this point? I agree, I wouldn't use
    sbrk() either. I'd use malloc(). If you have a small number of fixed
    allocations declaring them in the bss for maximum compaction is an
    alternative as well. No fragmentation, no allocator overhead, etc.

    > (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?'')

    I'm not really sure why they would. It seems like it would lead to
    increaed ineffeciencies and fragmentation. In the kernel we keep moving
    towards fewer allocators not more for this exact reason.

    > 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?
    >

    It does start at 4k of allocated pages. I think I discussed this in my
    other email. WIth regards to the other pages that have been alllocated to
    this process.. I remembered this today while thinking about another
    problem. FreeBSD does prefaults to map pages that are already available
    into an address space. This significantly reduces the number of faults in
    many applications due to spacial locality. This probably acounts for the
    memory used that has not actually been referenced.

    FreeBSD and ELF just aren't well suited to extremely tiny binaries. I
    hope this answers your questions.

    > ---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: D. J. Bernstein: "Re: ten thousand small processes"

    Relevant Pages

    • Re: sbrk(2) broken
      ... I scratched my head for a long time as to why I was getting out of memory ... If sbrk() is indeed to be used by the default malloc, ... but are indeed coded with "modern virtual memory" (as ...
      (freebsd-current)
    • Re: ten thousand small processes
      ... "stack and data have different VM protections and, ... >> writing a general purpose malloc is significantly more complicated, ... Calling mallocfor the first time causes a 16K spike in memory usage under ... are wonderful decisions for a memory allocator tuned for a very ...
      (freebsd-performance)
    • Re: malloc options
      ... Malloc was significantly changed with 7.0 and reading through the malloc man page there are a number of flags that can be set with /etc/ malloc.conf. ... If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. ...
      (freebsd-questions)
    • Re: Alternative to C for system programming
      ... Malloc and Free, ... The execution times and memory efficiency of malloc and free are ... but it makes the allocator fragile. ...
      (comp.programming)
    • Re: Benchmark: STLs list vs. hand-coded one
      ... And having 64MB buffer allocated you will need to write your own new, ... or malloc() implementations to manage memory in the buffer and do ... unlikely that a custom memory allocator can be any faster than a generic ...
      (comp.arch.embedded)