Messages in this thread | | | Date | Thu, 06 Jul 2000 21:03:49 -0600 | From | Warren Young <> | Subject | Re: 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/
| |