On Mon, Jun 18, 2012 at 10:31 PM, David Rientjes <rientjes@xxxxxxxxxx> 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@xxxxxxxxxx>
> ---
> 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href