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

    • Re: [PATCH] - support inheritance of mlocks across fork/exec V2
      ... [vmas' VM_LOCKED flags for fork() and mm's def_flags ... Jeff Sharkey at Montana State developed a similar patch for Linux ... unsigned int token_priority; ...
      (Linux-Kernel)
    • Re: [RFC][PATCHSET] mremap/mmap mess
      ... the shm bug caught by dwg - in case of hugepage shm we ended up with ... I wondered why you don't pass the appropriate filp and pgoff here? ... and do_brkdisagree on whether they're MAP_ flags or VM_ flags ... and just stick to the pgoff fix here for this patch. ...
      (Linux-Kernel)
    • Re: [PATCH] reintroduce accept4
      ... in question I think there is no reason to quarantine the patch first. ... Introduce a new accept4() system call. ... except that it adds a flags bit-mask argument. ... int status = 0; ...
      (Linux-Kernel)
    • [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)