Re: [patch v2] mm, oom: do not schedule if current has been killed

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

On Mon, Jun 18, 2012 at 10:31 PM, David Rientjes <rientjes@google.com> wrote:
> The oom killer currently schedules away from current in an
> uninterruptible sleep if it does not have access to memory reserves.
> It's possible that current was killed because it shares memory with the
> oom killed thread or because it was killed by the user in the interim,
> however.
>
> This patch only schedules away from current if it does not have a pending
> kill, i.e. if it does not share memory with the oom killed thread, or is
> already exiting.  It's possible that it will immediately retry its memory
> allocation and fail, but it will immediately be given access to memory
> reserves if it calls the oom killer again.
>
> This prevents the delay of memory freeing when threads that share memory
> with the oom killed thread get unnecessarily scheduled.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  mm/oom_kill.c |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -746,10 +746,11 @@ out:
>        read_unlock(&tasklist_lock);
>
>        /*
> -        * Give "p" a good chance of killing itself before we
> +        * Give "p" a good chance of exiting before we
>         * retry to allocate memory unless "p" is current
>         */
> -       if (killed && !test_thread_flag(TIF_MEMDIE))
> +       if (killed && !fatal_signal_pending(current) &&
> +                     !(current->flags & PF_EXITING))
>                schedule_timeout_uninterruptible(1);
>  }

Why don't check gfp_flags? I think the rule is,

1) a thread of newly marked as TIF_MEMDIE
    -> now it has a capability to access reseve memory. let's immediately retry.
2) allocation for GFP_HIGHUSER_MOVABLE
    -> we can fail to allocate it safely. let's immediately fail.
        (I suspect we need to change page allocator too)
3) GFP_KERNEL and PF_EXITING
    -> don't retry immediately. It shall fail again. let's wait until
killed process
        is exited.



> @@ -765,6 +766,6 @@ void pagefault_out_of_memory(void)
>                out_of_memory(NULL, 0, 0, NULL, false);
>                clear_system_oom();
>        }
> -       if (!test_thread_flag(TIF_MEMDIE))
> +       if (!fatal_signal_pending(current) && !(current->flags & PF_EXITING))
>                schedule_timeout_uninterruptible(1);

This makes sense to me.

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