home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sun / admin / 6096 < prev    next >
Encoding:
Text File  |  1992-09-02  |  3.1 KB  |  88 lines
  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!jimbys
  3. From: jimbys@cco.caltech.edu (James V. Bys)
  4. Subject: How to GLOBALLY reduce data size?
  5. Message-ID: <1992Sep3.045851.10665@cco.caltech.edu>
  6. Summary: How can the default process data segment size be reduced globally?
  7. Keywords: data segment kernel patch
  8. Sender: news@cco.caltech.edu
  9. Nntp-Posting-Host: plug
  10. Organization: California Institute of Technology, Pasadena
  11. Date: Thu, 3 Sep 1992 04:58:51 GMT
  12. Lines: 74
  13.  
  14. The default data segment size for most Suns is a little less than 512
  15. Megabytes.  It seems unfair for one process to use up this much virtual memory,
  16. especially when the system in question is running as a server.
  17.  
  18. If the assumption is correct that one process can grab 512 MBs of virtual
  19. memory, then the question is how can the default limit be lowered
  20. system wide?
  21.  
  22. (This question also has a further assumption that most programs will be
  23.  reluctant to raise their default limit.  If this is not true the following
  24.  comments still apply to lowering the maximum limit.)
  25.  
  26. The "setrlimit" system call applies only to the process that calls it and its
  27. children.
  28.  
  29. There therefore appears to be only a few ways to enforce a new default
  30. data size:
  31.  
  32. 1) Reconfigure the kernel to have a new default size.
  33.  
  34. 2) Change the code for the init process (the father of all processes, right?)
  35. to call setrlimit.
  36.  
  37. 3) Change all allowable shells in /etc/shells, and all daemons that will
  38.    cause new processes to be formed to call setrlimit.
  39.  
  40. The only option that seems feasible without source is number 1).
  41.  
  42. But...
  43.  
  44. Here is what has been tried in building a new kernel:
  45.  
  46.  The file vmparam.h in /sys/k-arch was modified for the new reduced limit and
  47.  the kernel rebuilt.
  48.  
  49.  Apparently the code that would be affected by vmparam.h is precompiled,
  50.  however.
  51.  
  52.  That code appears to be in machdep.o (at least the symbols _dfldsiz and
  53.  _maxdsiz are defined there).
  54.  
  55.  Sun technical support suggested patching vmunix to put a new value in
  56.  _dfldsiz using adb but it appears that the contents of _dfldsiz does not 
  57.  exist in the "vmunix" file.
  58.  
  59.  _dfldsiz is accessible in the running kernel but then the new value would 
  60.  have to be patched every time the system is rebooted.
  61.  
  62.  In the running kernel _dfldsiz can be examined only in memory (/ command
  63.  to adb, not ?).
  64.  
  65.  This might make sense if _dfldsiz is not a static and a value is loaded
  66.  into it only when the system is running.
  67.  
  68.  It might also be that I just don't know how to find where its static value
  69.  is stored in vmunix.
  70.  
  71.  Tech support's suggestion was to use the command
  72.    
  73.      _dfldsiz/W <new-hex-value>
  74.  
  75.  in adb to modify vmunix.  But would this command not just modify memory?
  76.  
  77.  Now I know next to nothing about running adb so it is possible that some
  78.  other commands to adb would have been successful.
  79.  
  80.  An attempt was also made to search for the 32 bit value "1fffe000" 
  81.  (the normal default data size value) in vmunix and machdep.o without success.
  82.  
  83. Any help here would be appreciated.  Please point out any misguided assumptions
  84. and other methods for reducing the default size globally.
  85.  
  86. James V. Bys
  87. E-mail address: jimbys@cco.caltech.edu
  88.