[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160128223615.GB14803@dhcp22.suse.cz>
Date: Thu, 28 Jan 2016 23:36:16 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: akpm@...ux-foundation.org, hannes@...xchg.org, mgorman@...e.de,
rientjes@...gle.com, torvalds@...ux-foundation.org,
oleg@...hat.com, hughd@...gle.com, andrea@...nel.org,
riel@...hat.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/2] oom: clear TIF_MEMDIE after oom_reaper managed to
unmap the address space
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
> > > to start the OOM reaper as simple as possible (without being bothered by
> > > a lot of possible corner cases), please pursue a guaranteed last resort
> > > at the same time.
> >
> > I am getting tired of this level of argumentation. oom_reaper in its
> > current form is a step forward. I have acknowledged there are possible
> > improvements doable on top but I do not see them necessary for the core
> > part being merged. I am not trying to rush this in because I am very
> > well aware of how subtle and complex all the interactions might be.
> > So please stop your "we must have it all at once" attitude. This is
> > nothing we have to rush in. We are not talking about a regression which
> > has to be absolutely fixed in few days.
>
> I'm not asking you to merge a perfect version of oom_reaper from the
> beginning. I know it is too difficult. Instead, I'm asking you to allow
> using timeout based approaches (shown below) as temporarily workaround
> because there are environments which cannot wait for oom_reaper to become
> enough reliable. Would you please reply to the thread which proposed a
> guaranteed last resort (shown below)?
I really fail to see why you have to bring that part in this particular
thread or in any other oom related discussion. I didn't get to read
through that discussion and make my opinion yet.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists