Andrew Morton wrote:
On Thu, 12 Oct 2006 17:19:07 +0200
Nick Piggin <[email protected]> wrote:
On Thu, Oct 12, 2006 at 07:12:13PM +0400, Kirill Korotaev wrote:
Nick,
AFAICS, 1 page allocation which is done in page fault handler
can fail in the only case - OOM kills current, so if we failed
we should have TIF_MEMDIE and just kill current.
Selecting another process for killing if page fault fails means
taking another victim with the one being already killed.
Hi Kirill,
I don't quite understand you.
Kirill is claiming that the only occasion on which a pagefault handler would
get an oom is when it killed itself in the oom handler.
Well I don't think that should happen much. When the process gets OOM
killed,
it is given full access to all memory reserves, so it will be _less_ likely
to go OOM maybe.
Actually if you work it through, maybe that isn't the case -- our
infinite retry
logic in the allocator means that non OOM killed tasks will never return
NULL,
while the OOM task might just use up every single free page in the
system and
will eventually return NULL. In this case the system is probably on
death's door
though, so I don't know if it is worth worrying about.
If the page allocation fails in the
fault handler, we don't want to kill current if it is marked as
OOM_DISABLE or sysctl_panic_on_oom is set... imagine a critical
service in a failover system.
It should be quite likely for another process to be kiled and
provide enough memory to keep the system running. Presuming you
have faith in the concept of the OOM killer ;)
I'm a bit wobbly about this one. Some before-and-after testing results
would help things along..
I can force VM_FAULT_OOMs to happen, but it is difficult to make it
happen in
the real world because most fault handling paths don't allocate higher order
allocations.
What I especially have in mind here is the OOM_DISABLE and panic_on_oom
sysctl
rather than expecting particularly much better general oom killing
behaviour.
Suppose you have a critical failover node or heartbeat process or something
where you'd rather the system to panic and reboot instead of doing something
silly...
--
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
