home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / aix / 11741 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  4.2 KB
  1. Path: sparky!uunet!olivea!pagesat!spssig.spss.com!brent
  2. From: brent@spss.com (Brent Lambert)
  3. Newsgroups: comp.unix.aix
  4. Subject: Re: Virtual Memory curiosity
  5. Keywords: VM overflow response
  6. Message-ID: <1992Nov19.210627.11604@spss.com>
  7. Date: 19 Nov 92 21:06:27 GMT
  8. References: <bmarlowe.721422470@ka> <1992Nov12.131230.130467@jrh.uucp> <1992Nov18.193645.11129@msuinfo.cl.msu.edu>
  9. Sender: news@spss.com (Net News Admin)
  10. Distribution: usa
  11. Organization: SPSS, Inc. - portable code group
  12. Lines: 70
  13.  
  14. In article <1992Nov18.193645.11129@msuinfo.cl.msu.edu>, boone@convex.cl.msu.edu (Dennis Boone) writes:
  15. > In article <1992Nov12.131230.130467@jrh.uucp> jrh@jrh.uucp (James R. Hamilton) writes:
  16. > >In article <bmarlowe.721422470@ka> bmarlowe@ka.reg.uci.edu (Brett Marlowe) writes:
  17. > >>I've heard rumor that AIX will pick processes to kill off to avoid
  18. > >>running out of virtual memory?  Can anyone verify this and if this is
  19. > >>true a) is there a way to disable this "feature" and b) what idiot
  20. > >>decided that randomly killing processes was a good idea??!!
  21. > >>
  22. > >    It is true that AIX will start killing process when it runs out of 
  23. > >    page space.  You can disable this feature (i.e. protect a process)
  24. > >    by it calling "signal(SIGDANGER, SIG_IGN)".  WRT to the idiot that
  25. > >    decided to randomly kill processes, the decision is not random -- 
  26. > >    processes are killed youngest first (in AIX 3.2) and if they ignore 
  27. > >    SIGDANGER then they are not killed at all.
  28. > 
  29. > I tend to agree with Brett.  The solution is completely non-portable and
  30. > non-standard, so out-of-the-box software has to be modified.  You can't
  31. > run a stable system if the o/s is going to run around whacking off
  32. > important processes.  The fact that the decision isn't really random makes
  33. > no difference: it still isn't possible to tell which processes will get
  34. > the axe without keeping continuous track of every new process.
  35.  
  36. I've previously posted suggestions for IBM to improve memory allocation to 
  37. make our lives less "fun", so clearly I'm not happy about the current
  38. implementation.  On the other hand, I really don't think that the problem
  39. is as significant as it's being made out to be.
  40.  
  41. For one thing, is there such a thing as portable "out-of-the-box software",
  42. where a single executable file runs on both AIX and non-AIX machines?  I
  43. think not.  Therefore, "out-of-the-box software" is either coded for, or 
  44. ported to, AIX.  Part of porting software includes dealing with platform-
  45. specific issues.  If your favorite application doesn't work well on your
  46. platform of choice, it's because the application vendor failed to code it
  47. or port it properly.
  48.  
  49. Being an application developer, I don't like to deal with platform-specific
  50. issues like this, but if my program crashes because of AIX's memory
  51. allocation strategy, it's my fault, not IBM's.  And since most systems have
  52. problems in the portability and standard area, I just expect to deal with
  53. them (sigh).
  54.  
  55. As for whacking off (important processes), if a process is important, it
  56. should be doing a lot of things to look after itself, including catching
  57. SIGDANGER.  One might even say that a program which doesn't catch SIGDANGER
  58. and then try to free up some paging space is not very 'neighborly'.  Of 
  59. course, if you don't have access to the code, and it's designed to be an
  60. "important process", then refer to my two previous paragraphs.
  61.  
  62. In the same vein, if you have consistent problems with processes getting
  63. killed due to a shortage of page space, that's probably a good sign that
  64. you need more paging space.
  65.  
  66. As far as knowing "which processes will get the axe" is concerned, it's
  67. pretty predictable, something like the youngest process that doesn't catch
  68. SIGDANGER goes next.  There's more to it than that, but the algorithm has
  69. been discussed here before, so you can look it up.
  70.  
  71. Finally, as others have pointed out, 
  72.     Ignoring danger could get you killed;
  73.     Noticing danger could keep you alive;
  74.     Doing something about the danger is your best bet.
  75.  
  76. So catch SIGDANGER, then do as you please.
  77.  
  78.  
  79. -- 
  80. The above statements are not the opinions or policies of SPSS Inc.
  81. The above statements may not be the opinions of Brent Lambert.
  82. The first disclaimer is a policy of SPSS Inc.
  83. Subsequent disclaimers are probably the opinion of Brent Lambert.
  84.