If Linux provided both of those, then people would probably already be
> ...with the current model it's quite possible the handler code is still
> sitting on the disk and no memory will be available to page it in.
Actually, I see SIGDANGER being useful at the time we hit freepages.min
(or maybe even freepages.low), rather than actual OOM so that the apps
have a chance to DO something about the memory shortage, rather than just
waiting around to die.
On AIX, if a process gets SIGDANGER without a registered signal handler,
the process is terminated. It would be nice to send SIGDANGER to
processes when we hit freepages.low (signal ignored by unsupporting apps),
and again when we hit freepages.min (signal will terminate usupporting
apps), and only after that do we start SIGKILLing processes. However,
I'm not sure if the kernel can affect the SIG_DFL actions for apps or not.
> at present the SIGDANGER bloat would be just a fake excuse but wouldn't
> address the root of problems at all.
I see SIGDANGER as being complementary to any other changes to the OOM
killer. Obviously, there are some issues with the VM/OOM killer when it
is killing processes rather than flushing dirty buffers and such. But
even when this is fixed, SIGDANGER is useful for applications which
optimistically allocate RAM/swap for cache that can be freed easily.
Yes, applications need to be changed to use SIGDANGER, but high-end
applications that also run on AIX likely have such code already under
"#ifdef SIGDANGER" or similar (I'm thinking Oracle, etc). If not,
then you can't expect anyone to start putting it into Linux apps
until SIGDANGER actually exists...
-- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/