Re: [PATCH v3] mm,page_alloc: wait for oom_lock than back off

[Michal Hocko <mhocko@kernel.org>]

On Wed 21-03-18 19:39:32, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > > But since Michal is still worrying that adding a single synchronization
> > > > point into the OOM path is risky (without showing a real life example
> > > > where lock_killable() in the coldest OOM path hurts), changes made by
> > > > this patch will be enabled only when oom_compat_mode=0 kernel command line
> > > > parameter is specified so that users can test whether their workloads get
> > > > hurt by this patch.
> > > > 
> > > Nacked with passion. This is absolutely hideous. First of all there is
> > > absolutely no need for the kernel command line. That is just trying to
> > > dance around the fact that you are not able to argue for the change
> > > and bring reasonable arguments on the table. We definitely do not want
> > > two subtly different modes for the oom handling. Secondly, and repeatedly,
> > > you are squashing multiple changes into a single patch. And finally this
> > > is too big of a hammer for something that even doesn't solve the problem
> > > for PREEMPTIVE kernels which are free to schedule regardless of the
> > > sleep or the reclaim retry you are so passion about.
> > 
> > So, where is your version? Offload to a kernel thread like the OOM reaper?
> > Get rid of oom_lock? Just rejecting my proposal makes no progress.
> > 
> Did you come up with some idea?
> Even CONFIG_PREEMPT=y, as far as I tested, v2 patch significantly reduces stalls than now.
> I believe there is no valid reason not to test my v2 patch at linux-next.

There are and I've mentioned them in my review feedback.

-- 
Michal Hocko
SUSE Labs