Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-02-15 Thread Tetsuo Handa
Andrew Morton wrote: > > The patch titled > Subject: mm/oom_kill.c: don't ignore oom score on exiting tasks > has been removed from the -mm tree. Its filename was > mm-oom_killc-dont-skip-pf_exiting-tasks-when-searching-for-a-victim.patch > > This patch was dropped because an updated v

Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-01-28 Thread Michal Hocko
On Fri 29-01-16 07:26:39, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 28-01-16 20:24:36, Tetsuo Handa wrote: > > [...] > > > I like the OOM reaper approach but I can't agree on merging the OOM reaper > > > without providing a guaranteed last resort at the same time. If you do > > > want >

Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-01-28 Thread Michal Hocko
I have missed one important point. exit_oom_victim has to do test_and_clear to make sure we do not race now with this patch. So we need to fold the following into the patch --- >From 296166b049ceb8b3199019a24aebab032998ebb0 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Thu, 28 Jan 2016 23:27:2

Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-01-28 Thread Tetsuo Handa
Michal Hocko wrote: > On Thu 28-01-16 20:24:36, Tetsuo Handa wrote: > [...] > > I like the OOM reaper approach but I can't agree on merging the OOM reaper > > without providing a guaranteed last resort at the same time. If you do want > > to start the OOM reaper as simple as possible (without being

Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-01-28 Thread Michal Hocko
On Thu 28-01-16 20:24:36, Tetsuo Handa wrote: [...] > I like the OOM reaper approach but I can't agree on merging the OOM reaper > without providing a guaranteed last resort at the same time. If you do want > to start the OOM reaper as simple as possible (without being bothered by > a lot of possib

Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-01-28 Thread Tetsuo Handa
Michal Hocko wrote: > On Mon 18-01-16 13:35:44, Tetsuo Handa wrote: > [...] > > (1) Make the OOM reaper available on CONFIG_MMU=n kernels. > > > > I don't know about MMU, but I assume we can handle these errors. > > What is the usecase for this on !MMU configurations? Why does it make > sense

Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to unmap the address space

2016-01-26 Thread Michal Hocko
On Mon 18-01-16 13:35:44, Tetsuo Handa wrote: [...] > (1) Make the OOM reaper available on CONFIG_MMU=n kernels. > > I don't know about MMU, but I assume we can handle these errors. What is the usecase for this on !MMU configurations? Why does it make sense to add more code to such a restrict