On 10/19/2007 12:01 AM, Rene Herman wrote:
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.
Well, no, that "guarantee" is fairly badly formulated but I mean "before
everyone got a SIGTERM" ofcourse. That is, first do the same selection as
now but don't send KILL but TERM and mark the task as having received a TERM
already and make it not eligible anymore. Only when there are no TERM
eligible tasks anymore, start sending KILL.
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]
