[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1607141324290.68666@chino.kir.corp.google.com>
Date: Thu, 14 Jul 2016 13:26:30 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
cc: mpatocka@...hat.com, mhocko@...nel.org, okozina@...hat.com,
jmarchan@...hat.com, skozina@...hat.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: System freezes after OOM
On Thu, 14 Jul 2016, Tetsuo Handa wrote:
> David Rientjes wrote:
> > On Wed, 13 Jul 2016, Mikulas Patocka wrote:
> >
> > > What are the real problems that f9054c70d28bc214b2857cf8db8269f4f45a5e23
> > > tries to fix?
> > >
> >
> > It prevents the whole system from livelocking due to an oom killed process
> > stalling forever waiting for mempool_alloc() to return. No other threads
> > may be oom killed while waiting for it to exit.
>
> Is that concern still valid? We have the OOM reaper for CONFIG_MMU=y case.
>
Umm, show me an explicit guarantee where the oom reaper will free memory
such that other threads may return memory to this process's mempool so it
can make forward progress in mempool_alloc() without the need of utilizing
memory reserves. First, it might be helpful to show that the oom reaper
is ever guaranteed to free any memory for a selected oom victim.
Powered by blists - more mailing lists