Re: OOM notifications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/18/2007 11:18 PM, Rik van Riel wrote:

On Thu, 18 Oct 2007 23:06:52 +0200
Rene Herman <[email protected]> wrote:

They don't -- that's why I asked if you need both scenario's active
at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
the operator deciding through setting the level at which point
applications get it.

Or put differently; what's the additional value of notifying an
application that the system is about to go balistic when you've
already asked it to free all it could earlier? SIGSEEDAMNITITOLDYOUSO?

The first threshold - "we are about to swap" - means the application
frees memory that it can.  Eg. free()d memory that glibc has not yet
given back to the kernel, or JVM running the garbage collector, or ...

The second threshold - "we are out of memory" - means that the first
approach has failed and the system needs to do something else. On an
embedded system, I would expect some application to exit or maybe
restart itself.

That first threshold sounds fine yes. To me, the second mostly sounds like a job for SIGTERM though.

The OOM killer could after it selected the task for killing first try a TERM on it to give a chance to exit gracefully and only when that doesn't help make it eligible for killing on a second round through the badness calculation.

You could moreover _never_ make a task eligible for killing before it received a SIGTERM, thereby guaranteeing that everyone got the SIGTERM before killing anything, and it seems SIGTERM would be a more focussed version of SIGDANGER2 then.

Would at least forego any need for multiplexing the DANGER signal.

Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux