RE: ten thousand small processes

From: Pedram Nimreezi (Support_at_Netflag.Net)
Date: 06/22/03

  • Next message: David O'Brien: "Re: ten thousand small processes"
    Date: Sun, 22 Jun 2003 04:45:39 -0700
    To: freebsd-performance@freebsd.org
    
    

    I'm sure Professor Bernstein wouldn't have a problem doing so.
    However, I think he's implying a gross oversight...

    At 03:50 AM 6/22/2003 -0400, Michael E. Conlen wrote:
    >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@freebsd.org
    >[mailto:owner-freebsd-performance@freebsd.org]On Behalf Of D. J.
    >Bernstein
    >Sent: Saturday, June 21, 2003 2:58 PM
    >To: freebsd-performance@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@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"

    _______________________________________________
    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: David O'Brien: "Re: ten thousand small processes"

    Relevant Pages

    • ten thousand small processes
      ... Where is all that DRAM going? ... I don't care much about the 3-page text segment. ... which uses 84 bytes of data and 316 bytes of bss. ... libc implementors clearly don't care about 316 bytes of memory, ...
      (freebsd-performance)
    • RE: ten thousand small processes
      ... If your going to get this serious about your memory management, ... Where is all that DRAM going? ... I don't care much about the 3-page text segment. ... which uses 84 bytes of data and 316 bytes of bss. ...
      (freebsd-performance)
    • Re: GC performance - GC fragility
      ... I take care ). ... memory in an endless loop doesn't eat all the systems memory. ... reference an object that has been collected in the same way that you can ... otherwise allocation a single object would result in 100 ...
      (borland.public.delphi.non-technical)
    • Re: GC performance - GC fragility
      ... I rather prefer to know the details, but having not to care about them during coding. ... which does nothing more than allocating memory in an endless loop doesn't eat all the systems memory. ... For these kind of resources even in a GC environment reference counting is needed. ... If my application has a significant performance decrease, when using .NET compare to the native implementation then yes, I wouldn't let the customer pay for it. ...
      (borland.public.delphi.non-technical)
    • Re: Different Implementations of VLIW .
      ... | did they cost anywhere close to $25,000 (not even after adding memory ... Note that at the $5000/system price we were getting almost *no* margin ... I don't know whether you're talking "OEM cost" or "retail ... If you ignore our artificially low initial DRAM sales ...
      (comp.arch)