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