Re: [RFC PATCH 2/2] mm,oom: Try last second allocation after selecting an OOM victim.

[Michal Hocko <mhocko@suse.com>]

On Wed 25-10-17 21:15:24, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Wed 25-10-17 19:48:09, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > [...]
> > > > The OOM killer is the last hand break. At the time you hit the OOM
> > > > condition your system is usually hard to use anyway. And that is why I
> > > > do care to make this path deadlock free. I have mentioned multiple times
> > > > that I find real life triggers much more important than artificial DoS
> > > > like workloads which make your system unsuable long before you hit OOM
> > > > killer.
> > > 
> > > Unable to invoke the OOM killer (i.e. OOM lockup) is worse than hand break injury.
> > > 
> > > If you do care to make this path deadlock free, you had better stop depending on
> > > mutex_trylock(&oom_lock). Not only printk() from oom_kill_process() can trigger
> > > deadlock due to console_sem versus oom_lock dependency but also
> > 
> > And this means that we have to fix printk. Completely silent oom path is
> > out of question IMHO
> 
> We cannot fix printk() without giving enough CPU resource to printk().

This is a separate discussion but having a basically unbound time spent
in printk is simply a no-go.
 
> I don't think "Completely silent oom path" can happen, for warn_alloc() is called
> again when it is retried. But anyway, let's remove warn_alloc().

I mean something else. We simply cannot do the oom killing without
telling userspace about that. And printk is the only API we can use for
that.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>