On Tue 19-07-16 16:27:59, Andrew Morton wrote:
> On Tue, 19 Jul 2016 14:05:39 +0200 Michal Hocko wrote:
>
> > > After this patch we should guarantee a forward progress for the OOM
> > > killer even when the selected victim is sharing memory with a kernel
> > > thread or global init.
> >
> > Coul
On Tue, 19 Jul 2016 14:05:39 +0200 Michal Hocko wrote:
> > After this patch we should guarantee a forward progress for the OOM
> > killer even when the selected victim is sharing memory with a kernel
> > thread or global init.
>
> Could you replace the last two paragraphs with the following. Tet
Andrew,
On Mon 20-06-16 14:43:48, Michal Hocko wrote:
> From: Michal Hocko
>
> The only case where the oom_reaper is not triggered for the oom victim
> is when it shares the memory with a kernel thread (aka use_mm) or with
> the global init. After "mm, oom: skip vforked tasks from being selected
From: Michal Hocko
The only case where the oom_reaper is not triggered for the oom victim
is when it shares the memory with a kernel thread (aka use_mm) or with
the global init. After "mm, oom: skip vforked tasks from being selected"
the victim cannot be a vforked task of the global init so we ar
Tetsuo Handa wrote:
> But this is not safe for CONFIG_MMU=y kernels as well.
> can_oom_reap == false means that oom_reap_task() will not be called.
> It is possible that the TIF_MEMDIE thread falls into
>
>atomic_read(&task->signal->oom_victims) > 0 && find_lock_task_mm(task) ==
> NULL
>
> s
Michal Hocko wrote:
> On Fri 10-06-16 00:15:18, Tetsuo Handa wrote:
> [...]
> > Nobody will set MMF_OOM_REAPED flag if can_oom_reap == true on
> > CONFIG_MMU=n kernel. If a TIF_MEMDIE thread in CONFIG_MMU=n kernel
> > is blocked before exit_oom_victim() in exit_mm() from do_exit() is
> > called, th
On Wed 15-06-16 16:37:01, Oleg Nesterov wrote:
> Michal,
>
> I am going to ack the whole series, but send some nits/questions,
>
> On 06/09, Michal Hocko wrote:
> >
> > @@ -283,10 +283,22 @@ enum oom_scan_t oom_scan_process_thread(struct
> > oom_control *oc,
> >
> > /*
> > * This task
Michal,
I am going to ack the whole series, but send some nits/questions,
On 06/09, Michal Hocko wrote:
>
> @@ -283,10 +283,22 @@ enum oom_scan_t oom_scan_process_thread(struct
> oom_control *oc,
>
> /*
>* This task already has access to memory reserves and is being killed.
> -
On Fri 10-06-16 00:15:18, Tetsuo Handa wrote:
[...]
> Nobody will set MMF_OOM_REAPED flag if can_oom_reap == true on
> CONFIG_MMU=n kernel. If a TIF_MEMDIE thread in CONFIG_MMU=n kernel
> is blocked before exit_oom_victim() in exit_mm() from do_exit() is
> called, the system will lock up. This is n
Michal Hocko wrote:
> The only case where the oom_reaper is not triggered for the oom victim
> is when it shares the memory with a kernel thread (aka use_mm) or with
> the global init. After "mm, oom: skip vforked tasks from being selected"
> the victim cannot be a vforked task of the global init s
From: Michal Hocko
The only case where the oom_reaper is not triggered for the oom victim
is when it shares the memory with a kernel thread (aka use_mm) or with
the global init. After "mm, oom: skip vforked tasks from being selected"
the victim cannot be a vforked task of the global init so we ar
On Mon 06-06-16 15:26:50, Michal Hocko wrote:
[...]
> @@ -922,8 +941,17 @@ void oom_kill_process(struct oom_control *oc, struct
> task_struct *p,
> }
> rcu_read_unlock();
>
> - if (can_oom_reap)
> + if (can_oom_reap) {
> wake_oom_reaper(victim);
> + } else i
On Sat 04-06-16 00:16:32, Tetsuo Handa wrote:
[...]
> Leaving current thread from out_of_memory() without clearing TIF_MEMDIE might
> cause OOM lockup, for there is no guarantee that current thread will not wait
> for locks in unkillable state after current memory allocation request
> completes
>
On Sat 04-06-16 00:16:32, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > The only case where the oom_reaper is not triggered for the oom victim
> > is when it shares the memory with a kernel thread (aka use_mm) or with
> > the global init. After "mm, oom: skip vforked tasks from being selected"
> >
Michal Hocko wrote:
> The only case where the oom_reaper is not triggered for the oom victim
> is when it shares the memory with a kernel thread (aka use_mm) or with
> the global init. After "mm, oom: skip vforked tasks from being selected"
> the victim cannot be a vforked task of the global init s
From: Michal Hocko
The only case where the oom_reaper is not triggered for the oom victim
is when it shares the memory with a kernel thread (aka use_mm) or with
the global init. After "mm, oom: skip vforked tasks from being selected"
the victim cannot be a vforked task of the global init so we ar
16 matches
Mail list logo
