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 <[email protected]>
Signed-off-by: David Rientjes <[email protected]>
---
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;
}
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 <[email protected]>
> Signed-off-by: David Rientjes <[email protected]>
Acked-by: Rik van Riel <[email protected]>
--
All rights reversed.
On Sun, Jun 7, 2009 at 3:42 AM, David Rientjes<[email protected]> 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 <[email protected]>
> Signed-off-by: David Rientjes <[email protected]>
Seems like a good change to make. Did you encounter this situation on
a real machine?
Balbir
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.
> 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 <[email protected]>
> Signed-off-by: David Rientjes <[email protected]>
it seems reasonable.
thanks.
Reviewed-by: KOSAKI Motohiro <[email protected]>
Hi, David.
On Mon, Jun 8, 2009 at 8:18 AM, David Rientjes<[email protected]> 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