Bug 20402

Hi!

We don't currently have a way to map slab usage back to an individual task, so we can't target the offending task easily without trying to hack counters into all the possible places where you can allocate a substantial amount of slab.

There is work currently on-going specifically for the memory controller that will account for slab and charge it to a hard limit.  That doesn't quite solve the problem, though, unless you've been constrained to your own memory controller if the motivation happens to be malicious.

We've recently seen similar things with excessively long arguments that are passed when executing a program: the memory allocated by the kernel doesn't actually get charged to task being exec'd, so the oom killer ends up killing another task since the memory usage of that new task is always very low at this point.

So there are several examples where this can happen, and yours would be another to add to the list.  I'm interested in seeing your particular example, though, so if you could attach it to this bugzilla entry, I'd appreciate it.

Thanks!

I've been dying over the past three months to see your usecase that allows an innocent task to be killed by the oom killer :)  This bug hasn't been active, so if you have an example I'd be happy to look at it and see if there's any way we can attribute the memory usage to the correct task.  (Slab, as mentioned previously, is going to be difficult outside of a memory controller environment, however.)

2011/1/26 <bugzilla-daemon@bugzilla.kernel.org>

> https://bugzilla.kernel.org/show_bug.cgi?id=20402
>
>
> --- Comment #2 from David Rientjes <rientjes@google.com>  2011-01-26
> 10:06:15 ---
> I've been dying over the past three months to see your usecase that allows
> an
> innocent task to be killed by the oom killer :)  This bug hasn't been
> active,
> so if you have an example I'd be happy to look at it and see if there's any
> way
> we can attribute the memory usage to the correct task.  (Slab, as mentioned
> previously, is going to be difficult outside of a memory controller
> environment, however.)
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

Well. I do not fully undestand which memory can be named slab.

data in unix sockets? in pipes? in network sockets? in posix IPC messages ?


One interesting example: if I mmap() some big area ( maximum available
vmsize set by ulimit) and try to write it as one big block into a file. In
fact, my process became unkillable (goes into uninterruptible sleep) until
kernel writes completely that block into a file. During that time my
memory-mapped area is the property of the malicious process, and it will eat
RSS more and more. But such process can not be killed until it completes
writing. Also, I can mlock() that pages to make situation worse.

(http://linux-mm.org/OOM_Killer)

Current OOM killer does not detect processes with memory leaks. For example,
If simple database server has memory leak, it will have big piece of
ANONYMOUS memory in the swap, but relatively small count of pages in RSS.
Suppose, another process eat some amount of memory. Now, OOM killer should
do it's action. It will detect that process that eat maximum of rss memory
is the second process and will kill it. But more appropriate decision will
be to kill database server. It's logically valid: OOM appear when bot RSS
and ANONYMOUS MEMORY SWAP exhausted.

So, OOM killer should count not only RSS memory, but

BADNESS = LOCKED PAGES * 10 + UNLOCKED ANONYMOUS RSS * 5 + ANONYMOUS SWAP
(coefficients 10 and 5 are random, but it mean what i want to implement)

for example:
* NTP server will lock itself with mlockall():  ~5MB * 10 = 50 points.
* leaky database server: 50MB*5 + 1000MB  = 1250 points
* innocent application  2*10 + 50*5 + 10 = 280 points
* firefox:
* JVM:
* Virtualbox:

Also, why not to kill processes sorted by SUM (LOCKED NON-ANONYMOUS  +
 ANONYMOUS ) ???

Also, why not to activate KSM (kernel samepage merging) on memory which is
not marked as available for that operation, intead of killing processes ??
KSM, especially for zero-filled pages may recover some memory at small cost.
In our situation (linux with big bunch of chroots), KSM for same pages in
"unshared" shared libraries will help very strongly.