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

    • System clock APIs and feed-forward clock integration with BPF (was "Re: svn commit: r227778 -
      ... one of the new flags when the kernel doesn't have FFCLOCK ... This patch will hopefully be MFCed at some point, ... we drop the union in the BPF header and followed something similar to what Ben and you proposed. ... There 3 orthogonal parameters to the timestamping function in the BPF context: ...
      (freebsd-arch)
    • 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)