mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [patch -mmotm] oom: only oom kill exiting tasks with attached memory
@ 2009-06-06 22:12 David Rientjes
  2009-06-07 14:06 ` Rik van Riel
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: David Rientjes @ 2009-06-06 22:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Rik van Riel, linux-kernel

When a task is chosen for oom kill and is found to be PF_EXITING,
__oom_kill_task() is called to elevate the task's timeslice and give it
access to memory reserves so that it may quickly exit.

This privilege is unnecessary, however, if the task has already detached
its mm.  Although its possible for the mm to become detached later since
task_lock() is not held, __oom_kill_task() will simply be a no-op in such
circumstances.

Subsequently, it is no longer necessary to warn about killing mm-less
tasks since it is a no-op.

Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: David Rientjes <rientjes@google.com>
---
 mm/oom_kill.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -325,11 +325,8 @@ static void __oom_kill_task(struct task_struct *p, int verbose)
 		return;
 	}
 
-	if (!p->mm) {
-		WARN_ON(1);
-		printk(KERN_WARNING "tried to kill an mm-less task!\n");
+	if (!p->mm)
 		return;
-	}
 
 	if (verbose)
 		printk(KERN_ERR "Killed process %d (%s)\n",
@@ -397,8 +394,9 @@ static int oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int order,
 	/*
 	 * If the task is already exiting, don't alarm the sysadmin or kill
 	 * its children or threads, just set TIF_MEMDIE so it can die quickly
+	 * if its mm is still attached.
 	 */
-	if (p->flags & PF_EXITING) {
+	if (p->mm && (p->flags & PF_EXITING)) {
 		__oom_kill_task(p, 0);
 		return 0;
 	}

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch -mmotm] oom: only oom kill exiting tasks with attached memory
  2009-06-06 22:12 [patch -mmotm] oom: only oom kill exiting tasks with attached memory David Rientjes
@ 2009-06-07 14:06 ` Rik van Riel
  2009-06-07 14:12 ` Balbir Singh
  2009-06-08  1:08 ` KOSAKI Motohiro
  2 siblings, 0 replies; 6+ messages in thread
From: Rik van Riel @ 2009-06-07 14:06 UTC (permalink / raw)
  To: David Rientjes; +Cc: Andrew Morton, linux-kernel

David Rientjes wrote:
> When a task is chosen for oom kill and is found to be PF_EXITING,
> __oom_kill_task() is called to elevate the task's timeslice and give it
> access to memory reserves so that it may quickly exit.
> 
> This privilege is unnecessary, however, if the task has already detached
> its mm.  Although its possible for the mm to become detached later since
> task_lock() is not held, __oom_kill_task() will simply be a no-op in such
> circumstances.
> 
> Subsequently, it is no longer necessary to warn about killing mm-less
> tasks since it is a no-op.
> 
> Cc: Rik van Riel <riel@redhat.com>
> Signed-off-by: David Rientjes <rientjes@google.com>

Acked-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch -mmotm] oom: only oom kill exiting tasks with attached  memory
  2009-06-06 22:12 [patch -mmotm] oom: only oom kill exiting tasks with attached memory David Rientjes
  2009-06-07 14:06 ` Rik van Riel
@ 2009-06-07 14:12 ` Balbir Singh
  2009-06-07 23:18   ` David Rientjes
  2009-06-08  1:08 ` KOSAKI Motohiro
  2 siblings, 1 reply; 6+ messages in thread
From: Balbir Singh @ 2009-06-07 14:12 UTC (permalink / raw)
  To: David Rientjes; +Cc: Andrew Morton, Rik van Riel, linux-kernel

On Sun, Jun 7, 2009 at 3:42 AM, David Rientjes<rientjes@google.com> wrote:
> When a task is chosen for oom kill and is found to be PF_EXITING,
> __oom_kill_task() is called to elevate the task's timeslice and give it
> access to memory reserves so that it may quickly exit.
>
> This privilege is unnecessary, however, if the task has already detached
> its mm.  Although its possible for the mm to become detached later since
> task_lock() is not held, __oom_kill_task() will simply be a no-op in such
> circumstances.
>
> Subsequently, it is no longer necessary to warn about killing mm-less
> tasks since it is a no-op.
>
> Cc: Rik van Riel <riel@redhat.com>
> Signed-off-by: David Rientjes <rientjes@google.com>

Seems like a good change to make. Did you encounter this situation on
a real machine?

Balbir

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch -mmotm] oom: only oom kill exiting tasks with attached memory
  2009-06-07 14:12 ` Balbir Singh
@ 2009-06-07 23:18   ` David Rientjes
  2009-06-08 15:21     ` Minchan Kim
  0 siblings, 1 reply; 6+ messages in thread
From: David Rientjes @ 2009-06-07 23:18 UTC (permalink / raw)
  To: Balbir Singh; +Cc: Andrew Morton, Rik van Riel, linux-kernel

On Sun, 7 Jun 2009, Balbir Singh wrote:

> Seems like a good change to make. Did you encounter this situation on
> a real machine?
> 

I did, as the result of the chosen task remaining in PF_EXITING state with 
a detached mm following a previous oom kill.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch -mmotm] oom: only oom kill exiting tasks with attached memory
  2009-06-06 22:12 [patch -mmotm] oom: only oom kill exiting tasks with attached memory David Rientjes
  2009-06-07 14:06 ` Rik van Riel
  2009-06-07 14:12 ` Balbir Singh
@ 2009-06-08  1:08 ` KOSAKI Motohiro
  2 siblings, 0 replies; 6+ messages in thread
From: KOSAKI Motohiro @ 2009-06-08  1:08 UTC (permalink / raw)
  To: David Rientjes; +Cc: kosaki.motohiro, Andrew Morton, Rik van Riel, linux-kernel

> When a task is chosen for oom kill and is found to be PF_EXITING,
> __oom_kill_task() is called to elevate the task's timeslice and give it
> access to memory reserves so that it may quickly exit.
> 
> This privilege is unnecessary, however, if the task has already detached
> its mm.  Although its possible for the mm to become detached later since
> task_lock() is not held, __oom_kill_task() will simply be a no-op in such
> circumstances.
> 
> Subsequently, it is no longer necessary to warn about killing mm-less
> tasks since it is a no-op.
> 
> Cc: Rik van Riel <riel@redhat.com>
> Signed-off-by: David Rientjes <rientjes@google.com>

it seems reasonable.
thanks.

	Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [patch -mmotm] oom: only oom kill exiting tasks with attached  memory
  2009-06-07 23:18   ` David Rientjes
@ 2009-06-08 15:21     ` Minchan Kim
  0 siblings, 0 replies; 6+ messages in thread
From: Minchan Kim @ 2009-06-08 15:21 UTC (permalink / raw)
  To: David Rientjes; +Cc: Balbir Singh, Andrew Morton, Rik van Riel, linux-kernel

Hi, David.

On Mon, Jun 8, 2009 at 8:18 AM, David Rientjes<rientjes@google.com> wrote:
> On Sun, 7 Jun 2009, Balbir Singh wrote:
>
>> Seems like a good change to make. Did you encounter this situation on
>> a real machine?
>>
>
> I did, as the result of the chosen task remaining in PF_EXITING state with
> a detached mm following a previous oom kill.
> --

Let me have a question.
If I understand your situation properly, you mean

Time order
t1 < t2 < t3 < t4.

t1 : oom kill A process - send signal. it doesn't destroy mm_struct yet.
t2 : destroy A's mm_struct but it is in task list.
t3 : It happens OOM, again. Process A is selected again since it still
remain in task list
t4 : Now A's mm_struct is destroyed => situation you said.

Is right ?
Do you turn on sysctl oom_kill_allocating_task ?

-- 
Kinds regards,
Minchan Kim

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-06-08 15:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-06 22:12 [patch -mmotm] oom: only oom kill exiting tasks with attached memory David Rientjes
2009-06-07 14:06 ` Rik van Riel
2009-06-07 14:12 ` Balbir Singh
2009-06-07 23:18   ` David Rientjes
2009-06-08 15:21     ` Minchan Kim
2009-06-08  1:08 ` KOSAKI Motohiro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®