Thread (55 messages) 55 messages, 8 authors, 2012-11-01

Re: zram OOM behavior

From: David Rientjes <rientjes@google.com>
Date: 2012-10-31 18:54:09

On Wed, 31 Oct 2012, Minchan Kim wrote:
It sounds right in your kernel but principal problem is min_filelist_kbytes patch.
If normal exited process in exit path requires a page and there is no free page
any more, it ends up going to OOM path after try to reclaim memory several time.
Then,
In select_bad_process,

        if (task->flags & PF_EXITING) {
               if (task == current)             <== true
                        return OOM_SCAN_SELECT;
In oom_kill_process,

        if (p->flags & PF_EXITING)
                set_tsk_thread_flag(p, TIF_MEMDIE);

At last, normal exited process would get a free page.
select_bad_process() won't actually select the process for oom kill, 
though, if there are other PF_EXITING threads other than current.  So if 
multiple threads are page faulting on tsk->robust_list, then no thread 
ends up getting killed.  The temporary workaround would be to do a kill -9 
so that the logic in out_of_memory() could immediately give such threads 
access to memory reserves so the page fault will succeed.  The real fix 
would be to audit all possible cases in between setting 
tsk->flags |= PF_EXITING and tsk->mm = NULL that could cause a memory 
allocation and make exemptions for them in oom_scan_process_thread().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help