Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1336218 > unrolled thread

[PATCH 0/6] preparation for merging the OOM reaper

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/6] preparation for merging the OOM reaper Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:30 +0100
    [PATCH 1/6] mm,oom: exclude TIF_MEMDIE processes from candidates. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:30 +0100
      Re: [PATCH 1/6] mm,oom: exclude TIF_MEMDIE processes from candidates. Michal Hocko <mhocko@kernel.org> - 2016-02-17 13:50 +0100
        Re: [PATCH 1/6] mm,oom: exclude TIF_MEMDIE processes from candidates. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 17:50 +0100
          Re: [PATCH 1/6] mm,oom: exclude TIF_MEMDIE processes from candidates. Michal Hocko <mhocko@kernel.org> - 2016-02-17 18:40 +0100
            Re: [PATCH 1/6] mm,oom: exclude TIF_MEMDIE processes from candidates. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 22:00 +0100
    [PATCH 6/6] mm,oom: wait for OOM victims when using oom_kill_allocating_task == 1 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:40 +0100
      Re: [PATCH 6/6] mm,oom: wait for OOM victims when using  oom_kill_allocating_task == 1 Michal Hocko <mhocko@kernel.org> - 2016-02-17 14:40 +0100
        Re: [PATCH 6/6] mm,oom: wait for OOM victims when using oom_kill_allocating_task == 1 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-18 11:50 +0100
          Re: [PATCH 6/6] mm,oom: wait for OOM victims when using  oom_kill_allocating_task == 1 Michal Hocko <mhocko@kernel.org> - 2016-02-18 13:30 +0100
    [PATCH 4/6] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:40 +0100
      Re: [PATCH 4/6] mm,oom: exclude oom_task_origin processes if they  are OOM-unkillable. Michal Hocko <mhocko@kernel.org> - 2016-02-17 14:20 +0100
        Re: [PATCH 4/6] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 14:40 +0100
          Re: [PATCH 4/6] mm,oom: exclude oom_task_origin processes if they  are OOM-unkillable. Michal Hocko <mhocko@kernel.org> - 2016-02-17 14:50 +0100
    [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:40 +0100
      Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when  selecting a victim. Michal Hocko <mhocko@kernel.org> - 2016-02-17 14:00 +0100
        Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 14:10 +0100
          Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when  selecting a victim. Michal Hocko <mhocko@kernel.org> - 2016-02-17 15:10 +0100
            Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 15:50 +0100
              Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when  selecting a victim. Michal Hocko <mhocko@kernel.org> - 2016-02-17 16:10 +0100
                Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 16:30 +0100
                  Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when  selecting a victim. Michal Hocko <mhocko@kernel.org> - 2016-02-17 17:20 +0100
                    Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-18 12:30 +0100
    [PATCH 3/6] mm,oom: exclude oom_task_origin processes if they are OOM victims. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:40 +0100
      Re: [PATCH 3/6] mm,oom: exclude oom_task_origin processes if they  are OOM victims. Michal Hocko <mhocko@kernel.org> - 2016-02-17 14:10 +0100
    [PATCH 5/6] mm,oom: Re-enable OOM killer using timers. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-02-17 11:40 +0100
      Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers. Michal Hocko <mhocko@kernel.org> - 2016-02-17 14:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1336516 — Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim.

Michal Hocko wrote:
> > > > Please see http://lkml.kernel.org/r/201602151958.HCJ48972.FFOFOLMHSQVJtO@I-love.SAKURA.ne.jp .
> > > 
> > > I have missed this one. Reading...
> > > 
> > > Hmm, so you are not referring to OOM killed task but naturally exiting
> > > thread which is racing with the OOM killer. I guess you have a point
> > > there! Could you update the changelog with the above example and repost
> > > please?
> > > 
> > Yes and I resent that patch as v2.
> > 
> > I think that the same problem exists for any task_will_free_mem()-based
> > optimizations. Can we eliminate them because these optimized paths are not
> > handled by the OOM reaper which means that we have no means other than
> > "[PATCH 5/6] mm,oom: Re-enable OOM killer using timers." ?
> 
> Well, only oom_kill_process usage of task_will_free_mem might be a
> problem because out_of_memory operates on the current task so it must be
> in the allocation path and access to memory reserves should help it to
> continue.

Allowing access to memory reserves by task_will_free_mem(current) in
out_of_memory() will help current to continue, but that does not guarantee
that current will not be later blocked at down_read(&current->mm->mmap_sem).
It is possible that one of threads sharing current thread's memory is calling
out_of_memory() from mmap() and is waiting for current to set
current->mm = NULL.

> Wrt. oom_kill_process this will be more tricky. I guess we want to
> teach oom_reaper to operate on such a task which would be a more robust
> solution than removing the check altogether.
> 

Thus, I think there is no difference between task_will_free_mem(current)
case and task_will_free_mem(p) case. We want to teach the OOM reaper to
operate whenever TIF_MEMDIE is set. But this means that we want
mm_is_reapable() check because there might be !SIGKILL && !PF_EXITING
threads when we run these optimized paths. We will need to use timer
if mm_is_reapable() == false after all.

Why don't you accept timer based workaround now, even if you have a plan
to update the OOM reaper for handling these optimized paths?

[toc] | [prev] | [next] | [standalone]

#1336558 — Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim.

On Thu 18-02-16 00:29:35, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > > > Please see http://lkml.kernel.org/r/201602151958.HCJ48972.FFOFOLMHSQVJtO@I-love.SAKURA.ne.jp .
> > > > 
> > > > I have missed this one. Reading...
> > > > 
> > > > Hmm, so you are not referring to OOM killed task but naturally exiting
> > > > thread which is racing with the OOM killer. I guess you have a point
> > > > there! Could you update the changelog with the above example and repost
> > > > please?
> > > > 
> > > Yes and I resent that patch as v2.
> > > 
> > > I think that the same problem exists for any task_will_free_mem()-based
> > > optimizations. Can we eliminate them because these optimized paths are not
> > > handled by the OOM reaper which means that we have no means other than
> > > "[PATCH 5/6] mm,oom: Re-enable OOM killer using timers." ?
> > 
> > Well, only oom_kill_process usage of task_will_free_mem might be a
> > problem because out_of_memory operates on the current task so it must be
> > in the allocation path and access to memory reserves should help it to
> > continue.
> 
> Allowing access to memory reserves by task_will_free_mem(current) in
> out_of_memory() will help current to continue, but that does not guarantee
> that current will not be later blocked at down_read(&current->mm->mmap_sem).
> It is possible that one of threads sharing current thread's memory is calling
> out_of_memory() from mmap() and is waiting for current to set
> current->mm = NULL.
>
> > Wrt. oom_kill_process this will be more tricky. I guess we want to
> > teach oom_reaper to operate on such a task which would be a more robust
> > solution than removing the check altogether.
> > 
> 
> Thus, I think there is no difference between task_will_free_mem(current)
> case and task_will_free_mem(p) case.

Yes you are right! I completely managed to confuse and misled myself.

> We want to teach the OOM reaper to
> operate whenever TIF_MEMDIE is set. But this means that we want
> mm_is_reapable() check because there might be !SIGKILL && !PF_EXITING
> threads when we run these optimized paths.

> We will need to use timer if mm_is_reapable() == false after all.

Or we should re-evaluate those heuristics for multithreaded processes.
Does it even make sense to shortcut and block the OOM killer if the
single thread is exiting? Only very small amount of memory gets released
during its exit anyway. Don't we want to catch only the group exit to
catch fatal_signal_pending -> exit_signals -> exit_mm -> allocation
cases? I am not really sure what to check for, to be honest though.

> Why don't you accept timer based workaround now, even if you have a plan
> to update the OOM reaper for handling these optimized paths?

Because I believe that the timeout based solutions are distracting from
a proper solution which would be based on actual algorithm/heurstic that
can be measured and evaluated. And because I can see future discussion
of whether $FOO or $BAR is a better timeout... I really do not see any
reason to rush into quick solutions now.

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1337286 — Re: [PATCH 2/6] mm,oom: don't abort on exiting processes when selecting a victim.

Michal Hocko wrote:
> > We want to teach the OOM reaper to
> > operate whenever TIF_MEMDIE is set. But this means that we want
> > mm_is_reapable() check because there might be !SIGKILL && !PF_EXITING
> > threads when we run these optimized paths.
>
> > We will need to use timer if mm_is_reapable() == false after all.
>
> Or we should re-evaluate those heuristics for multithreaded processes.

TIF_MEMDIE heuristics are per a task_struct basis but OOM-kill operation
is per a signal_struct basis or per a mm_struct basis.

Since we set TIF_MEMDIE to only one thread (with a wrong assumption that
remaining threads will get TIF_MEMDIE due to fatal_signal_pending()),
we are bothered by corner cases.

> Does it even make sense to shortcut and block the OOM killer if the
> single thread is exiting?

Do we check for clone(!CLONE_SIGHAND && CLONE_VM) threads (i.e. walk the
process list) for checking whether it is really a single thread?
That would be mm_is_reapable().

>                           Only very small amount of memory gets released
> during its exit anyway.

Currently exit_mm() is called before exit_files() etc. are called.
Can we expect a single page of memory being released when such thread
gets stuck at down_read(&mm->mmap_sem) ?

>                         Don't we want to catch only the group exit to
> catch fatal_signal_pending -> exit_signals -> exit_mm -> allocation
> cases? I am not really sure what to check for, to be honest though.
>

I don't know what this line is saying.

> > Why don't you accept timer based workaround now, even if you have a plan
> > to update the OOM reaper for handling these optimized paths?
>
> Because I believe that the timeout based solutions are distracting from
> a proper solution which would be based on actual algorithm/heurstic that
> can be measured and evaluated. And because I can see future discussion
> of whether $FOO or $BAR is a better timeout... I really do not see any
> reason to rush into quick solutions now.

OOM-livelock bugs are caused by over-throttling based on optimistic
assumptions. This [PATCH 5/6] patch is for unthrottling in order to
guarantee forward progress (and eventually trigger kernel panic if
there is no more OOM-killable processes).

I can't see future discussion of whether $FOO or $BAR is a better timeout
because timeout based unthrottling should seldom occur. Even without the
OOM reaper, more than e.g. 99% of innocent OOM events would successfully
solve the OOM condition before this timeout expires. After we merge the
OOM reaper, more than e.g. 99% of malicious OOM events would successfully
solve the OOM condition before this timeout expires. Who can gather data
for discussing whether $FOO or $BAR is a better timeout? Only those who want
to explore this e.g. 1% possibility and those who hate any timeout would
want to disable this timeout.

If we make sure that timeout based unthrottling guarantees forward
progress, we can try to utilize memory reserves more aggressively.
For example, we can set TIF_MEMDIE on all fatal_signal_pending() threads
using a mm_struct chosen by the OOM killer. This will eliminate a wrong
assumption that remaining threads will get TIF_MEMDIE due to
fatal_signal_pending(). We had been too cowardly about use of memory
reserves because currently we have no means to refill the memory reserves.
If timeout based unthrottling kills next OOM victim (and the OOM reaper
reaps it), we can overcommit memory reserves (like we overcommit normal
memory).

I don't think we can manage without timeout based solutions.
I really do not see any reason not to accept [PATCH 5/6] now.

[toc] | [prev] | [next] | [standalone]

#1336234 — [PATCH 3/6] mm,oom: exclude oom_task_origin processes if they are OOM victims.

>From f5531e726caad7431020c027b6900a8e2c678345 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Wed, 17 Feb 2016 16:32:37 +0900
Subject: [PATCH 3/6] mm,oom: exclude oom_task_origin processes if they are OOM victims.

Currently, oom_scan_process_thread() returns OOM_SCAN_SELECT when there
is a thread which returns oom_task_origin() == true. But it is possible
that that thread is sharing memory with OOM-unkillable processes or the
OOM reaper fails to reclaim enough memory. In that case, we must not
continue selecting such threads forever.

This patch changes oom_scan_process_thread() not to select a thread
which returns oom_task_origin() = true if TIF_MEMDIE is already set
because SysRq-f case can reach here. Since "mm,oom: exclude TIF_MEMDIE
processes from candidates." made sure that we will choose a !TIF_MEMDIE
thread when only some of threads are marked TIF_MEMDIE, we don't need to
check all threads which returns oom_task_origin() == true.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 mm/oom_kill.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index a3868fd..b0c327d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -308,7 +308,7 @@ enum oom_scan_t oom_scan_process_thread(struct oom_control *oc,
 	 * If task is allocating a lot of memory and has been marked to be
 	 * killed first if it triggers an oom, then select it.
 	 */
-	if (oom_task_origin(task))
+	if (oom_task_origin(task) && !test_tsk_thread_flag(task, TIF_MEMDIE))
 		return OOM_SCAN_SELECT;
 
 	return OOM_SCAN_OK;
-- 
1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1336411 — Re: [PATCH 3/6] mm,oom: exclude oom_task_origin processes if they are OOM victims.

On Wed 17-02-16 19:32:00, Tetsuo Handa wrote:
> >From f5531e726caad7431020c027b6900a8e2c678345 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Wed, 17 Feb 2016 16:32:37 +0900
> Subject: [PATCH 3/6] mm,oom: exclude oom_task_origin processes if they are OOM victims.
> 
> Currently, oom_scan_process_thread() returns OOM_SCAN_SELECT when there
> is a thread which returns oom_task_origin() == true. But it is possible
> that that thread is sharing memory with OOM-unkillable processes or the
> OOM reaper fails to reclaim enough memory. In that case, we must not
> continue selecting such threads forever.
> 
> This patch changes oom_scan_process_thread() not to select a thread
> which returns oom_task_origin() = true if TIF_MEMDIE is already set
> because SysRq-f case can reach here. Since "mm,oom: exclude TIF_MEMDIE
> processes from candidates." made sure that we will choose a !TIF_MEMDIE
> thread when only some of threads are marked TIF_MEMDIE, we don't need to
> check all threads which returns oom_task_origin() == true.

I do not think this is necessary. If you simply do OOM_SCAN_CONTINUE for
TIF_MEMDIE && is_sysrq_oom then you should be covered AFAICS.

> 
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
>  mm/oom_kill.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index a3868fd..b0c327d 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -308,7 +308,7 @@ enum oom_scan_t oom_scan_process_thread(struct oom_control *oc,
>  	 * If task is allocating a lot of memory and has been marked to be
>  	 * killed first if it triggers an oom, then select it.
>  	 */
> -	if (oom_task_origin(task))
> +	if (oom_task_origin(task) && !test_tsk_thread_flag(task, TIF_MEMDIE))
>  		return OOM_SCAN_SELECT;
>  
>  	return OOM_SCAN_OK;
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1336240 — [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

>From 6f07b71c97766ec111d26c3424bded465ca48195 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Wed, 17 Feb 2016 16:37:01 +0900
Subject: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

We are trying to reduce the possibility of hitting OOM livelock by
introducing the OOM reaper, but there are situations where the OOM reaper
cannot reap the victim's memory. We want to introduce the OOM reaper as
simple as possible and make the OOM reaper better via incremental
development.

This patch adds a timer for handling corner cases where a TIF_MEMDIE
thread got stuck by reasons not handled by the initial version of the
OOM reaper. Since "mm,oom: exclude TIF_MEMDIE processes from candidates."
made sure that we won't choose the same OOM victim forever and this patch
makes sure that the kernel automatically presses SysRq-f upon OOM stalls,
we will not OOM stall forever as long as the OOM killer is called.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 mm/oom_kill.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index ebc6764..fba2c62 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -45,6 +45,11 @@ int sysctl_oom_dump_tasks = 1;
 
 DEFINE_MUTEX(oom_lock);
 
+static void oomkiller_reset(unsigned long arg)
+{
+}
+static DEFINE_TIMER(oomkiller_victim_wait_timer, oomkiller_reset, 0, 0);
+
 #ifdef CONFIG_NUMA
 /**
  * has_intersects_mems_allowed() - check task eligiblity for kill
@@ -299,7 +304,8 @@ enum oom_scan_t oom_scan_process_thread(struct oom_control *oc,
 	 */
 	if (test_tsk_thread_flag(task, TIF_MEMDIE)) {
 		if (!is_sysrq_oom(oc))
-			return OOM_SCAN_ABORT;
+			return timer_pending(&oomkiller_victim_wait_timer) ?
+				OOM_SCAN_ABORT : OOM_SCAN_CONTINUE;
 	}
 	if (!task->mm)
 		return OOM_SCAN_CONTINUE;
@@ -452,6 +458,8 @@ void mark_oom_victim(struct task_struct *tsk)
 	 */
 	__thaw_task(tsk);
 	atomic_inc(&oom_victims);
+	/* Make sure that we won't wait for this task forever. */
+	mod_timer(&oomkiller_victim_wait_timer, jiffies + 5 * HZ);
 }
 
 /**
-- 
1.8.3.1

[toc] | [prev] | [next] | [standalone]

#1336416 — Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

On Wed 17-02-16 19:34:46, Tetsuo Handa wrote:
> >From 6f07b71c97766ec111d26c3424bded465ca48195 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Wed, 17 Feb 2016 16:37:01 +0900
> Subject: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.
> 
> We are trying to reduce the possibility of hitting OOM livelock by
> introducing the OOM reaper, but there are situations where the OOM reaper
> cannot reap the victim's memory. We want to introduce the OOM reaper as
> simple as possible and make the OOM reaper better via incremental
> development.
> 
> This patch adds a timer for handling corner cases where a TIF_MEMDIE
> thread got stuck by reasons not handled by the initial version of the
> OOM reaper. Since "mm,oom: exclude TIF_MEMDIE processes from candidates."
> made sure that we won't choose the same OOM victim forever and this patch
> makes sure that the kernel automatically presses SysRq-f upon OOM stalls,
> we will not OOM stall forever as long as the OOM killer is called.

Can we actually start by incremental changes first and only get to this
after we cannot find a proper way to fix existing issues?

I would like to at least make mmap_sem taken for write killable
first. This should allow the oom_reaper to make a forward progress and
allow the OOM killer to select another task when necessary (e.g. the
victim wasn't sitting on a large amount of reclaimable memory). This
has an advantage that the TIF_MEMDIE release is bound to a clearly
defined action rather than a $RANDOM timemout which will always be hard
to justify. We can talk about timeout based solutions after we are able
to livelock the system even after all well defined actions will have
failed. I really consider it premature right now.

> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
>  mm/oom_kill.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index ebc6764..fba2c62 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -45,6 +45,11 @@ int sysctl_oom_dump_tasks = 1;
>  
>  DEFINE_MUTEX(oom_lock);
>  
> +static void oomkiller_reset(unsigned long arg)
> +{
> +}
> +static DEFINE_TIMER(oomkiller_victim_wait_timer, oomkiller_reset, 0, 0);
> +
>  #ifdef CONFIG_NUMA
>  /**
>   * has_intersects_mems_allowed() - check task eligiblity for kill
> @@ -299,7 +304,8 @@ enum oom_scan_t oom_scan_process_thread(struct oom_control *oc,
>  	 */
>  	if (test_tsk_thread_flag(task, TIF_MEMDIE)) {
>  		if (!is_sysrq_oom(oc))
> -			return OOM_SCAN_ABORT;
> +			return timer_pending(&oomkiller_victim_wait_timer) ?
> +				OOM_SCAN_ABORT : OOM_SCAN_CONTINUE;
>  	}
>  	if (!task->mm)
>  		return OOM_SCAN_CONTINUE;
> @@ -452,6 +458,8 @@ void mark_oom_victim(struct task_struct *tsk)
>  	 */
>  	__thaw_task(tsk);
>  	atomic_inc(&oom_victims);
> +	/* Make sure that we won't wait for this task forever. */
> +	mod_timer(&oomkiller_victim_wait_timer, jiffies + 5 * HZ);
>  }
>  
>  /**
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web