Re: zram OOM behavior

[Luigi Semenzato <semenzato@google.com>]

On Thu, Nov 1, 2012 at 2:50 PM, David Rientjes <rientjes@google.com> wrote:
> On Thu, 1 Nov 2012, Luigi Semenzato wrote:
>
>> > @@ -706,11 +693,11 @@ void out_of_memory(struct zonelist *zonelist, gfp_t gfp_mask,
>> >                 return;
>> >
>> >         /*
>> > -        * If current has a pending SIGKILL, then automatically select it.  The
>> > -        * goal is to allow it to allocate so that it may quickly exit and free
>> > -        * its memory.
>> > +        * If current has a pending SIGKILL or is exiting, then automatically
>> > +        * select it.  The goal is to allow it to allocate so that it may
>> > +        * quickly exit and free its memory.
>> >          */
>> > -       if (fatal_signal_pending(current)) {
>> > +       if (fatal_signal_pending(current) || current->flags & PF_EXITING) {
>> >                 set_thread_flag(TIF_MEMDIE);
>> >                 return;
>> >         }
>>
>> I tested this change with my load and it appears to also prevent the deadlocks.
>>
>> I have a question though.  I thought only one process was allowed to
>> be in TIF_MEMDIE state, but I don't see anything that prevents this
>> code (before or after the change) from setting the flag in multiple
>> processes.  Is this a problem?
>>
>
> The code you've quoted above, prior to being changed by the patch, allows
> any thread with a fatal signal to have access to memory reserves, so it's
> certainly not only one thread with TIF_MEMDIE set at a time (the oom
> killer is not the only thing that can kill a thread).  The goal of that
> code is to ensure anything that has been killed can allocate successfully
> wherever it happens to be running so that it can handle the signal, exit,
> and free its memory.  My patch is extending that for all threads that are
> in the exit path that happen to require memory to exit to prevent a
> livelock.

I see.  But then I am wondering: if there is no limit to the number of
threads that can access the reserved memory, then is it possible that
that memory will be exhausted?  Is the size of the reserved memory
based on heuristics then?

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