On Tue 10-07-18 14:12:28, David Rientjes wrote:
> On Tue, 10 Jul 2018, David Rientjes wrote:
>
> > I think it's better, thanks. However, does it address the question about
> > why __oom_reap_task_mm() needs oom_lock protection? Perhaps it would be
> > helpful to mention synchronization between
On Tue, 10 Jul 2018, David Rientjes wrote:
> I think it's better, thanks. However, does it address the question about
> why __oom_reap_task_mm() needs oom_lock protection? Perhaps it would be
> helpful to mention synchronization between reaping triggered from
> oom_reaper and by exit_mmap().
On Tue, 10 Jul 2018, Michal Hocko wrote:
> What do you think about the following?
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index ed9d473c571e..32e6f7becb40 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -53,6 +53,14 @@ int sysctl_panic_on_oom;
> int sysctl_oom_kill_allocating_ta
On Mon 09-07-18 15:49:53, David Rientjes wrote:
> On Mon, 9 Jul 2018, Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent
> > munlock and oom reaper unmap, v3") we have a strong synchronization
> > between the oom_killer a
On Mon, 9 Jul 2018, Michal Hocko wrote:
> From: Michal Hocko
>
> Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent
> munlock and oom reaper unmap, v3") we have a strong synchronization
> between the oom_killer and victim's exiting because both have to take
> the oom_lock.
From: Michal Hocko
Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent
munlock and oom reaper unmap, v3") we have a strong synchronization
between the oom_killer and victim's exiting because both have to take
the oom_lock. Therefore the original heuristic to sleep for a short
6 matches
Mail list logo
