Re: zram OOM behavior

[Minchan Kim <minchan@kernel.org>]

Hi, 

Sorry for late response. I was traveling at that time and still suffer from
training course I never want. :(

On Fri, Oct 19, 2012 at 10:49:22AM -0700, Luigi Semenzato wrote:
> I found the source, and maybe the cause, of the problem I am
> experiencing when running out of memory with zram enabled.  It may be
> a known problem.  The OOM killer doesn't find any killable process
> because select_bad_process() keeps returning -1 here:
> 
>     /*
>      * This task already has access to memory reserves and is
>      * being killed. Don't allow any other task access to the
>      * memory reserve.
>      *
>      * Note: this may have a chance of deadlock if it gets
>      * blocked waiting for another task which itself is waiting
>      * for memory. Is there a better alternative?
>      */
>     if (test_tsk_thread_flag(p, TIF_MEMDIE)) {
>         if (unlikely(frozen(p)))
>             __thaw_task(p);
>         if (!force_kill)
>             return ERR_PTR(-1UL);
>     }
> 
> select_bad_process() is called by out_of_memory() in __alloc_page_may_oom().

I think it's not a zram problem but general problem of OOM killer.
Above code's intention is to prevent shortage of ememgency memory pool for avoding
deadlock. If we already killed any task and the task are in the middle of exiting,
OOM killer will wait for him to be exited. But the problem in here is that
killed task might wait any mutex which are held to another task which are
stuck for the memory allocation and can't use emergency memory pool. :(
It's a another deadlock, too. AFAIK, it's known problem and I'm not sure
OOM guys have a good idea. Cc'ed them.
I think one of solution is that if it takes some seconed(ex, 3 sec) after we already
kill some task but still looping with above code, we can allow accessing of
ememgency memory pool for another task. It may happen deadlock due to burn out memory
pool but otherwise, we still suffer from deadlock.

> 
> If this is the problem, I'd love to hear about solutions!
> 
> <BEGIN SHAMELESS PLUG>
> if we can get this to work, it will help keep the cost of laptops down!
> http://www.google.com/intl/en/chrome/devices/
> <END SHAMELESS PLUG>
> 
> P.S. Chromebooks are sweet things for kernel debugging because they
> boot so quickly (5-10s depending on the model).

But I think mainline kernel doesn't boot on that. :(

> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

--
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>