From: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
To: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Cc: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [patch 1/2] arch: invoke oom-killer from page fault
Date: Thu, 6 Jun 2013 16:59:40 +0200 [thread overview]
Message-ID: <20130606145940.GA24115@dhcp22.suse.cz> (raw)
In-Reply-To: <20130606043620.GA9406-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
On Thu 06-06-13 00:36:20, Johannes Weiner wrote:
> On Wed, Jun 05, 2013 at 08:57:44PM -0700, David Rientjes wrote:
> > On Wed, 5 Jun 2013, Johannes Weiner wrote:
> >
> > > Since '1c0fe6e mm: invoke oom-killer from page fault', page fault
> > > handlers should not directly kill faulting tasks in an out of memory
> > > condition.
> >
> > I have no objection to the patch, but there's no explanation given here
> > why exiting with a kill shouldn't be done. Is it because of memory
> > reserves and there is no guarantee that current will be able to exit? Or
> > is it just for consistency with other archs?
> >
> > > Instead, they should be invoking the OOM killer to pick
> > > the right task. Convert the remaining architectures.
> > >
> >
> > If this is a matter of memory reserves, I guess you could point people who
> > want the current behavior (avoiding the expensiveness of the tasklist scan
> > in the oom killer for example) to /proc/sys/vm/oom_kill_allocating_task?
> >
> > This changelog is a bit cryptic in its motivation.
>
> Fixing copy-pasted bitrot^W^W^W^WHow about this?
>
> ---
> From: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
> Subject: [patch] mm: invoke oom-killer from remaining unconverted page fault
> handlers
>
> A few remaining architectures directly kill the page faulting task in
> an out of memory situation. This is usually not a good idea since
> that task might not even use a significant amount of memory and so may
> not be the optimal victim to resolve the situation.
>
> Since '1c0fe6e mm: invoke oom-killer from page fault' (2.6.29) there
> is a hook that architecture page fault handlers are supposed to call
> to invoke the OOM killer and let it pick the right task to kill.
> Convert the remaining architectures over to this hook.
>
> To have the previous behavior of simply taking out the faulting task
> the vm.oom_kill_allocating_task sysctl can be set to 1.
>
> Signed-off-by: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
It was much easier than I thought.
Reviewed-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
> ---
> arch/arc/mm/fault.c | 6 ++++--
> arch/metag/mm/fault.c | 6 ++++--
> arch/mn10300/mm/fault.c | 7 ++++---
> arch/openrisc/mm/fault.c | 8 ++++----
> arch/score/mm/fault.c | 8 ++++----
> arch/tile/mm/fault.c | 8 ++++----
> 6 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
> index c0decc1..d5ec60a 100644
> --- a/arch/arc/mm/fault.c
> +++ b/arch/arc/mm/fault.c
> @@ -207,8 +207,10 @@ out_of_memory:
> }
> up_read(&mm->mmap_sem);
>
> - if (user_mode(regs))
> - do_group_exit(SIGKILL); /* This will never return */
> + if (user_mode(regs)) {
> + pagefault_out_of_memory();
> + return;
> + }
>
> goto no_context;
>
> diff --git a/arch/metag/mm/fault.c b/arch/metag/mm/fault.c
> index 2c75bf7..8fddf46 100644
> --- a/arch/metag/mm/fault.c
> +++ b/arch/metag/mm/fault.c
> @@ -224,8 +224,10 @@ do_sigbus:
> */
> out_of_memory:
> up_read(&mm->mmap_sem);
> - if (user_mode(regs))
> - do_group_exit(SIGKILL);
> + if (user_mode(regs)) {
> + pagefault_out_of_memory();
> + return 1;
> + }
>
> no_context:
> /* Are we prepared to handle this kernel fault? */
> diff --git a/arch/mn10300/mm/fault.c b/arch/mn10300/mm/fault.c
> index d48a84f..8a2e6de 100644
> --- a/arch/mn10300/mm/fault.c
> +++ b/arch/mn10300/mm/fault.c
> @@ -345,9 +345,10 @@ no_context:
> */
> out_of_memory:
> up_read(&mm->mmap_sem);
> - printk(KERN_ALERT "VM: killing process %s\n", tsk->comm);
> - if ((fault_code & MMUFCR_xFC_ACCESS) == MMUFCR_xFC_ACCESS_USR)
> - do_exit(SIGKILL);
> + if ((fault_code & MMUFCR_xFC_ACCESS) == MMUFCR_xFC_ACCESS_USR) {
> + pagefault_out_of_memory();
> + return;
> + }
> goto no_context;
>
> do_sigbus:
> diff --git a/arch/openrisc/mm/fault.c b/arch/openrisc/mm/fault.c
> index e2bfafc..4a41f84 100644
> --- a/arch/openrisc/mm/fault.c
> +++ b/arch/openrisc/mm/fault.c
> @@ -267,10 +267,10 @@ out_of_memory:
> __asm__ __volatile__("l.nop 1");
>
> up_read(&mm->mmap_sem);
> - printk("VM: killing process %s\n", tsk->comm);
> - if (user_mode(regs))
> - do_exit(SIGKILL);
> - goto no_context;
> + if (!user_mode(regs))
> + goto no_context;
> + pagefault_out_of_memory();
> + return;
>
> do_sigbus:
> up_read(&mm->mmap_sem);
> diff --git a/arch/score/mm/fault.c b/arch/score/mm/fault.c
> index 47b600e..6b18fb0 100644
> --- a/arch/score/mm/fault.c
> +++ b/arch/score/mm/fault.c
> @@ -172,10 +172,10 @@ out_of_memory:
> down_read(&mm->mmap_sem);
> goto survive;
> }
> - printk("VM: killing process %s\n", tsk->comm);
> - if (user_mode(regs))
> - do_group_exit(SIGKILL);
> - goto no_context;
> + if (!user_mode(regs))
> + goto no_context;
> + pagefault_out_of_memory();
> + return;
>
> do_sigbus:
> up_read(&mm->mmap_sem);
> diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
> index 3d2b81c..f7f99f9 100644
> --- a/arch/tile/mm/fault.c
> +++ b/arch/tile/mm/fault.c
> @@ -573,10 +573,10 @@ out_of_memory:
> down_read(&mm->mmap_sem);
> goto survive;
> }
> - pr_alert("VM: killing process %s\n", tsk->comm);
> - if (!is_kernel_mode)
> - do_group_exit(SIGKILL);
> - goto no_context;
> + if (is_kernel_mode)
> + goto no_context;
> + pagefault_out_of_memory();
> + return 0;
>
> do_sigbus:
> up_read(&mm->mmap_sem);
> --
> 1.8.2.3
>
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 1/2] arch: invoke oom-killer from page fault
Date: Thu, 6 Jun 2013 16:59:40 +0200 [thread overview]
Message-ID: <20130606145940.GA24115@dhcp22.suse.cz> (raw)
Message-ID: <20130606145940.Y41RI1WBKktNKNkOoXh04Kg8wLzT3iY_gIbEkqUY0xA@z> (raw)
In-Reply-To: <20130606043620.GA9406@cmpxchg.org>
On Thu 06-06-13 00:36:20, Johannes Weiner wrote:
> On Wed, Jun 05, 2013 at 08:57:44PM -0700, David Rientjes wrote:
> > On Wed, 5 Jun 2013, Johannes Weiner wrote:
> >
> > > Since '1c0fe6e mm: invoke oom-killer from page fault', page fault
> > > handlers should not directly kill faulting tasks in an out of memory
> > > condition.
> >
> > I have no objection to the patch, but there's no explanation given here
> > why exiting with a kill shouldn't be done. Is it because of memory
> > reserves and there is no guarantee that current will be able to exit? Or
> > is it just for consistency with other archs?
> >
> > > Instead, they should be invoking the OOM killer to pick
> > > the right task. Convert the remaining architectures.
> > >
> >
> > If this is a matter of memory reserves, I guess you could point people who
> > want the current behavior (avoiding the expensiveness of the tasklist scan
> > in the oom killer for example) to /proc/sys/vm/oom_kill_allocating_task?
> >
> > This changelog is a bit cryptic in its motivation.
>
> Fixing copy-pasted bitrot^W^W^W^WHow about this?
>
> ---
> From: Johannes Weiner <hannes@cmpxchg.org>
> Subject: [patch] mm: invoke oom-killer from remaining unconverted page fault
> handlers
>
> A few remaining architectures directly kill the page faulting task in
> an out of memory situation. This is usually not a good idea since
> that task might not even use a significant amount of memory and so may
> not be the optimal victim to resolve the situation.
>
> Since '1c0fe6e mm: invoke oom-killer from page fault' (2.6.29) there
> is a hook that architecture page fault handlers are supposed to call
> to invoke the OOM killer and let it pick the right task to kill.
> Convert the remaining architectures over to this hook.
>
> To have the previous behavior of simply taking out the faulting task
> the vm.oom_kill_allocating_task sysctl can be set to 1.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
It was much easier than I thought.
Reviewed-by: Michal Hocko <mhocko@suse.cz>
> ---
> arch/arc/mm/fault.c | 6 ++++--
> arch/metag/mm/fault.c | 6 ++++--
> arch/mn10300/mm/fault.c | 7 ++++---
> arch/openrisc/mm/fault.c | 8 ++++----
> arch/score/mm/fault.c | 8 ++++----
> arch/tile/mm/fault.c | 8 ++++----
> 6 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
> index c0decc1..d5ec60a 100644
> --- a/arch/arc/mm/fault.c
> +++ b/arch/arc/mm/fault.c
> @@ -207,8 +207,10 @@ out_of_memory:
> }
> up_read(&mm->mmap_sem);
>
> - if (user_mode(regs))
> - do_group_exit(SIGKILL); /* This will never return */
> + if (user_mode(regs)) {
> + pagefault_out_of_memory();
> + return;
> + }
>
> goto no_context;
>
> diff --git a/arch/metag/mm/fault.c b/arch/metag/mm/fault.c
> index 2c75bf7..8fddf46 100644
> --- a/arch/metag/mm/fault.c
> +++ b/arch/metag/mm/fault.c
> @@ -224,8 +224,10 @@ do_sigbus:
> */
> out_of_memory:
> up_read(&mm->mmap_sem);
> - if (user_mode(regs))
> - do_group_exit(SIGKILL);
> + if (user_mode(regs)) {
> + pagefault_out_of_memory();
> + return 1;
> + }
>
> no_context:
> /* Are we prepared to handle this kernel fault? */
> diff --git a/arch/mn10300/mm/fault.c b/arch/mn10300/mm/fault.c
> index d48a84f..8a2e6de 100644
> --- a/arch/mn10300/mm/fault.c
> +++ b/arch/mn10300/mm/fault.c
> @@ -345,9 +345,10 @@ no_context:
> */
> out_of_memory:
> up_read(&mm->mmap_sem);
> - printk(KERN_ALERT "VM: killing process %s\n", tsk->comm);
> - if ((fault_code & MMUFCR_xFC_ACCESS) == MMUFCR_xFC_ACCESS_USR)
> - do_exit(SIGKILL);
> + if ((fault_code & MMUFCR_xFC_ACCESS) == MMUFCR_xFC_ACCESS_USR) {
> + pagefault_out_of_memory();
> + return;
> + }
> goto no_context;
>
> do_sigbus:
> diff --git a/arch/openrisc/mm/fault.c b/arch/openrisc/mm/fault.c
> index e2bfafc..4a41f84 100644
> --- a/arch/openrisc/mm/fault.c
> +++ b/arch/openrisc/mm/fault.c
> @@ -267,10 +267,10 @@ out_of_memory:
> __asm__ __volatile__("l.nop 1");
>
> up_read(&mm->mmap_sem);
> - printk("VM: killing process %s\n", tsk->comm);
> - if (user_mode(regs))
> - do_exit(SIGKILL);
> - goto no_context;
> + if (!user_mode(regs))
> + goto no_context;
> + pagefault_out_of_memory();
> + return;
>
> do_sigbus:
> up_read(&mm->mmap_sem);
> diff --git a/arch/score/mm/fault.c b/arch/score/mm/fault.c
> index 47b600e..6b18fb0 100644
> --- a/arch/score/mm/fault.c
> +++ b/arch/score/mm/fault.c
> @@ -172,10 +172,10 @@ out_of_memory:
> down_read(&mm->mmap_sem);
> goto survive;
> }
> - printk("VM: killing process %s\n", tsk->comm);
> - if (user_mode(regs))
> - do_group_exit(SIGKILL);
> - goto no_context;
> + if (!user_mode(regs))
> + goto no_context;
> + pagefault_out_of_memory();
> + return;
>
> do_sigbus:
> up_read(&mm->mmap_sem);
> diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
> index 3d2b81c..f7f99f9 100644
> --- a/arch/tile/mm/fault.c
> +++ b/arch/tile/mm/fault.c
> @@ -573,10 +573,10 @@ out_of_memory:
> down_read(&mm->mmap_sem);
> goto survive;
> }
> - pr_alert("VM: killing process %s\n", tsk->comm);
> - if (!is_kernel_mode)
> - do_group_exit(SIGKILL);
> - goto no_context;
> + if (is_kernel_mode)
> + goto no_context;
> + pagefault_out_of_memory();
> + return 0;
>
> do_sigbus:
> up_read(&mm->mmap_sem);
> --
> 1.8.2.3
>
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2013-06-06 14:59 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 3:09 [patch 1/2] arch: invoke oom-killer from page fault Johannes Weiner
2013-06-06 3:09 ` Johannes Weiner
2013-06-06 3:09 ` [patch 2/2] memcg: do not sleep on OOM waitqueue with full charge context Johannes Weiner
2013-06-06 3:09 ` Johannes Weiner
2013-06-06 4:10 ` David Rientjes
2013-06-06 4:10 ` David Rientjes
2013-06-06 5:33 ` Johannes Weiner
2013-06-06 5:33 ` Johannes Weiner
2013-06-06 17:33 ` Johannes Weiner
2013-06-06 17:33 ` Johannes Weiner
2013-06-06 20:11 ` David Rientjes
2013-06-06 20:11 ` David Rientjes
2013-06-06 21:54 ` Johannes Weiner
2013-06-06 21:54 ` Johannes Weiner
2013-06-06 22:18 ` David Rientjes
2013-06-06 22:18 ` David Rientjes
2013-06-07 0:02 ` Johannes Weiner
2013-06-07 0:02 ` Johannes Weiner
2013-06-11 21:57 ` David Rientjes
2013-06-11 21:57 ` David Rientjes
2013-06-12 8:28 ` Michal Hocko
2013-06-12 8:28 ` Michal Hocko
[not found] ` <20130612082817.GA6706-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-06-12 20:12 ` David Rientjes
2013-06-12 20:12 ` David Rientjes
2013-06-12 20:37 ` Michal Hocko
2013-06-12 20:37 ` Michal Hocko
2013-06-12 20:49 ` David Rientjes
2013-06-12 20:49 ` David Rientjes
2013-06-13 13:48 ` Michal Hocko
2013-06-13 13:48 ` Michal Hocko
2013-06-13 20:34 ` David Rientjes
2013-06-13 20:34 ` David Rientjes
2013-06-14 9:29 ` Michal Hocko
2013-06-14 9:29 ` Michal Hocko
2013-06-06 15:23 ` Michal Hocko
2013-06-06 15:23 ` Michal Hocko
2013-06-06 3:57 ` [patch 1/2] arch: invoke oom-killer from page fault David Rientjes
2013-06-06 3:57 ` David Rientjes
2013-06-06 4:36 ` Johannes Weiner
2013-06-06 4:36 ` Johannes Weiner
2013-06-06 4:43 ` David Rientjes
2013-06-06 6:49 ` Vineet Gupta
2013-06-06 6:49 ` Vineet Gupta
[not found] ` <20130606043620.GA9406-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-06-06 14:59 ` Michal Hocko [this message]
2013-06-06 14:59 ` Michal Hocko
2013-06-06 4:55 ` 刘胜蛟
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130606145940.GA24115@dhcp22.suse.cz \
--to=mhocko-alswssmvlrq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).