> AIX will send the signal SIGDANGER to all processes before actually
> killing processes. By default SIGDANGER is ignored.
> Processes that have handlers for SIGDANGER are later skipped
> when searching for the real victim to kill.
This just screams "exploit me". What about a killer process
that used 'malloc()' as it's SIGDANGER handler? Since it has
a SIGDANGER handler it won't be killed...
Besides, having a SIGDANGER handler really doesn't say much
about the process being the cause of the OOM or not.
> Really, programs which use the standard malloc calls cannot
> do much on SIGDANGER but to be nice and exit, or bee bad and
> keep all their resources.
Sending SIGDANGER is a good idea. Not killing programs with
a SIGDANGER handler is, IMNSHO, a bad idea. We could give programs
which clean up 'on their own' a large bonus though (2x or 4x
less 'kill points').
> For Rik's patch:
> a. Processes that mmap physical memory
> segments may dangerous to kill just like processes that have
> direct I/O access. The general trend in hardware design is to
> use MMIO.
OK, how can I test for this?
> b. We need an option (per process) that the kernel will allways
> commit swap space. Such processes will fail calls to brk, sbrk,
> mmap, shmat, shmctl (did I miss anything) if sufficient swap
> space cannot be allocated. Such processes will be skipped when
> looking for victims to kill. I do not know if that belongs in
> the process' personality or elsewhere (does it already exist?)
We can also put it into libc. Having the process always touch
the pages it allocs will make sure that the process has it
available. Putting it into the kernel will have one advantage
though: we can just put the address of the allocated swap page
in the pagetable, together with a flag saying this is a 'fake'
page and we need to give the process a zero-filled page when it
starts using the page.
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html