Re: ten thousand small processes

From: Sean Chittenden (sean_at_chittenden.org)
Date: 07/01/03

  • Next message: Nick Evans: "Re: Tuning Gigabit" 
    Date: Mon, 30 Jun 2003 16:33:53 -0700
To: "D. J. Bernstein" <djb@cr.yp.to>

    > > Instead of complaining about wasting 78 megabytes and arguing
    > > about why various proposed solutions fall short and why your way
    > > is the best, why don't you come up with a patch that saves space
    > > for small programs?
    >
    > Funny. Seems to me that I keep making concrete
    > suggestions---including a detailed proposal for giving more space to
    > malloc()---and the answer is consistently ``We really don't care
    > about per-process overhead.'' What's the benefit of a patch for
    > people who don't even see the problem?

    It'd be slick if malloc(3) had a mallopt(3) call that'd make it easier
    to monkey with the _malloc_options, but, until such time as phk is on
    this list or decides to add such an interface, why not just set:

    _malloc_options = "<<<<<<<<<<<<<<<"; /* '<' * 15 */

    to reduce the malloc cache to 0? From malloc(3):

    TUNING
         Once, when the first call is made to one of these memory allocation rou-
         tines, various flags will be set or reset, which affect the workings of
         this allocation implementation.

         The ``name'' of the file referenced by the symbolic link named
         /etc/malloc.conf, the value of the environment variable MALLOC_OPTIONS,
         and the string pointed to by the global variable _malloc_options will be
         interpreted, in that order, character by character as flags.

         Most flags are single letters, where uppercase indicates that the behav-
         ior is set, or on, and lowercase means that the behavior is not set, or
         off.

    [snip]

         < Reduce the size of the cache by a factor of two. The default
                 cache size is 16 pages. This option can be specified multiple
                 times.

    -sc 

    -- 
Sean Chittenden
_______________________________________________
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: Nick Evans: "Re: Tuning Gigabit"

    Relevant Pages

    • [RFC 1/1] Char: mxser_new, fix recursive locking
      ... patch attached - I am not able to reproduce the lockup with this patch. ... determine whether the lock should be re-aquired or not. ... before calling all involved mxser_ routines. ... unsigned long flags; ...
      (Linux-Kernel)
    • [RFC] [PATCH] Per-mountpoint read-only and noatime revisited
      ... macro that makes use of the new flags. ... to the IS_* macro call are changed to pass the struct vfsmount* ... Furthermore, this patch adds the new functionality as new mount flags, ...
      (Linux-Kernel)
    • Re: *at family of syscalls in FreeBSD
      ... *at_getwd- In addition to your parameters, we also pass in the flags ... the subfile container if the user passed in O_XATTR (solaris uses this ... fd if you pass in an absolute path (I haven't looked at draft posix ... I am willing to adjust my patch with either the wrapping idea and/or the flags thing. ...
      (freebsd-arch)
    • Re: CPU Hotplug broken -mm5 onwards
      ... > I found that removing the lock in exec path has other consequences ... Found that lockless migration of execing task is _extremely_ racy. ... Anyway patch below addresses the above races. ... runqueue_t *rq; unsigned long flags; ...
      (Linux-Kernel)
    • Re: [RFC,PATCH] i2c: fix device_init_wakeup place
      ... Patch looked OK to me, except for the one comment below. ... and registeralways zero-initializes those wakeup flags. ... the simple act of probing a driver. ...
      (Linux-Kernel)