lkml.org 
[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.2.14 OOM killer strikes.
Derek Martin wrote:
>
> Doesn't it make the most sense to kill the process that caused the OOM?
> That seems the most logical thing to me...

It'd be nice if we could do that, but life is more difficult than that.

The first time your program asks for a little bit of memory, malloc()
goes and asks the kernel for a bunch of memory: tens of K at least,
maybe more. This is because it wants to minimize the number of memory
blocks, the number of syscalls, and the amount of memory fragmentation.

Now when malloc() asks for that memory, the kernel doesn't mark it as
in-use, and it doesn't assign it a place in real storage. Instead, it
maps it into the VM tables as unwritable memory. When someone writes to
the memory (first storage into the new memory), the kernel traps; it
realizes that the memory is now _really_ in use, so it marks it as
such. This optimization lets my piggy program ask for a megabyte of
memory, only use a few bytes of it, and not waste a bunch of real RAM.
(I do waste some VM, but that doesn't matter unless your system has real
memory for all or nearly all of the addressable memory: 4 GB on ia32.)

Now imagine a running system: each program has a bunch of memory
overcommitted. Right before the OOM event, RAM and swap are full with
in-use pages. Now one program tries to access one of its allocated but
unused pages. The kernel traps, tries to map the page into memory, and
fails.

Now what process should the kernel kill? The naive answer is the one
that caused the trap. But what if you've got a process with a memory
leak that happens to eat all the memory, then just before it grabs the
last bit of memory, the kernel schedules another process which touches
one of its overcommitted pages. What if that unfortunate process is,
say, syslogd or something critical like that?

System fall down go boom.

The right solution is resource accounting, which is coming to a kernel
near you sometime next year.
--
= Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

-
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.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.479 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site