[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160609154156.GG24777@dhcp22.suse.cz>
Date: Thu, 9 Jun 2016 17:41:57 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: linux-mm@...ck.org, rientjes@...gle.com, oleg@...hat.com,
vdavydov@...allels.com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/10] mm, oom: hide mm which is shared with kthread or
global init
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 not handled in the patch
> nor explained in the changelog.
I have made it clear several times that !CONFIG_MMU is not a target
of this patch series nor other OOM changes because I am not convinced
issues which we are trying to solve are real on those platforms. I
am not really sure what you are trying to achieve now with these
!CONFIG_MMU remarks but if you see _real_ regressions for those
configurations please describe them. This generic statements when
CONFIG_MMU implications are put into !CONFIG_MMU context are not really
useful. If there are possible OOM killer deadlocks without this series
then adding these patches shouldn't make them worse.
E.g. this particular patch is basically a noop for !CONFIG_MMU because
use_mm() is MMU specific. It is also highly improbable that a task would
share mm with init...
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists