Subject: Re: NetBSD1.6 UVM problem?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Oleg Polyanski <Oleg.Polianski@team.telstraclear.co.nz>
List: tech-kern
Date: 12/09/2002 23:48:13
>>>>> "dM" == der Mouse writes:

 dM> Yes, but that's not always possible.  There isn't always a
 dM> channel avialable to return ENOMEM, and when there is, it isn't
 dM> always easy to take advantage of it.

  AIX solves this problem by maintaining the yellow and red
  watermarks of the available amount of VM in a system. When the
  number reaches the yellow watermark, the kernel starts sending the
  SIGDANGEROUS signal to all the processes in the system. By
  default, when a process is started up, the SIGDANGEROUS bit in its
  signal mask is set to `ignore'. As soon as that number reaches the
  red watermark, the kernel starts killing all the processes, by
  starting from the largest one, that ignore the SIGDANGEROUS signal
  until the amount of VM gets up to the yellow watermark. Obviously,
  they solve two problems here: 1) they provide a sort of a callback
  telling a process that the system is under the low memory
  condition, and 2) the source code compatibility problem, i.e. a
  program doesn't need to know about the SIGDANGEROUS signal to be
  compiled under AIX while it's still a good idea to do that.

 dM> The worst case is perhaps when you're out of RAM servicing a
 dM> page fault.  There simply is no way to tell a process "I'm
 dM> sorry, you get ENOMEM instead of that page your PC is pointing
 dM> into".

  Fair enough, but what to do if you have a mission critical
  service? You end up with a killed process and perhaps lost data
  only because your kernel could not say anything about memory
  starvation rather killing the first found process happened to be
  the largest one.

Oleg