From: brent@spss.com (Brent Lambert)
Newsgroups: comp.unix.aix
Subject: Re: Virtual Memory curiosity
Keywords: VM overflow response
Date: 19 Nov 92 21:06:27 GMT
Distribution: usa
Organization: SPSS, Inc. - portable code group

In article <1992Nov18.193645.11129@msuinfo.cl.msu.edu>, boone@convex.cl.msu.edu (Dennis Boone) writes:
> In article <1992Nov12.131230.130467@jrh.uucp> jrh@jrh.uucp (James R. Hamilton) writes:
> >In article <bmarlowe.721422470@ka> bmarlowe@ka.reg.uci.edu (Brett Marlowe) writes:
> >>I've heard rumor that AIX will pick processes to kill off to avoid
> >>running out of virtual memory?  Can anyone verify this and if this is
> >>true a) is there a way to disable this "feature" and b) what idiot
> >>decided that randomly killing processes was a good idea??!!
> >>
> >    It is true that AIX will start killing process when it runs out of 
> >    page space.  You can disable this feature (i.e. protect a process)
> >    by it calling "signal(SIGDANGER, SIG_IGN)".  WRT to the idiot that
> >    decided to randomly kill processes, the decision is not random -- 
> >    processes are killed youngest first (in AIX 3.2) and if they ignore 
> >    SIGDANGER then they are not killed at all.
> 
> I tend to agree with Brett.  The solution is completely non-portable and
> non-standard, so out-of-the-box software has to be modified.  You can't
> run a stable system if the o/s is going to run around whacking off
> important processes.  The fact that the decision isn't really random makes
> no difference: it still isn't possible to tell which processes will get
> the axe without keeping continuous track of every new process.

I've previously posted suggestions for IBM to improve memory allocation to 
make our lives less "fun", so clearly I'm not happy about the current
implementation.  On the other hand, I really don't think that the problem
is as significant as it's being made out to be.

For one thing, is there such a thing as portable "out-of-the-box software",
where a single executable file runs on both AIX and non-AIX machines?  I
think not.  Therefore, "out-of-the-box software" is either coded for, or 
ported to, AIX.  Part of porting software includes dealing with platform-
specific issues.  If your favorite application doesn't work well on your
platform of choice, it's because the application vendor failed to code it
or port it properly.

Being an application developer, I don't like to deal with platform-specific
issues like this, but if my program crashes because of AIX's memory
allocation strategy, it's my fault, not IBM's.  And since most systems have
problems in the portability and standard area, I just expect to deal with
them (sigh).

As for whacking off (important processes), if a process is important, it
should be doing a lot of things to look after itself, including catching
SIGDANGER.  One might even say that a program which doesn't catch SIGDANGER
and then try to free up some paging space is not very 'neighborly'.  Of 
course, if you don't have access to the code, and it's designed to be an
"important process", then refer to my two previous paragraphs.

In the same vein, if you have consistent problems with processes getting
killed due to a shortage of page space, that's probably a good sign that
you need more paging space.

As far as knowing "which processes will get the axe" is concerned, it's
pretty predictable, something like the youngest process that doesn't catch
SIGDANGER goes next.  There's more to it than that, but the algorithm has
been discussed here before, so you can look it up.

Finally, as others have pointed out, 
    Ignoring danger could get you killed;
    Noticing danger could keep you alive;
    Doing something about the danger is your best bet.

So catch SIGDANGER, then do as you please.


-- 
The above statements are not the opinions or policies of SPSS Inc.
The above statements may not be the opinions of Brent Lambert.
The first disclaimer is a policy of SPSS Inc.
Subsequent disclaimers are probably the opinion of Brent Lambert.
Xref: sparky comp.unix.aix:11602 comp.mail.mh:1289