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

[Michal Hocko <mhocko@suse.com>]

On Tue 24-10-17 20:24:46, Tetsuo Handa wrote:
> Michal Hocko wrote:
[...]
> > > So, I think that worrying about high priority threads preventing the low
> > > priority thread with oom_lock held is too much. Preventing high priority
> > > threads waiting for oom_lock from disturbing the low priority thread with
> > > oom_lock held by wasting CPU resource will be sufficient.
> > 
> > In other words this is just to paper over an overloaded allocation path
> > close to OOM. Your changelog is really misleading in that direction
> > IMHO. I have to think some more about using the full lock rather than
> > the trylock, because taking the try lock is somehow easier.
> 
> Somehow easier to what? Please don't omit.

To back off on the oom races.

> I consider that the OOM killer is a safety mechanism in case a system got
> overloaded. Therefore, I really hate your comments like "Your system is already
> DOSed". It is stupid thing that safety mechanism drives the overloaded system
> worse and defunctional when it should rescue.

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.

> Current code is somehow easier to OOM lockup due to printk() versus oom_lock
> dependency, and I'm proposing a patch for mitigating printk() versus oom_lock
> dependency using oom_printk_lock because I can hardly examine OOM related
> problems since linux-4.9, and your response was "Hell no!".

Because you are repeatedly proposing a paper over rather than to attempt
something resembling a solution. And this is highly annoying. I've
already said that I am willing to sacrifice the stall warning rather
than fiddle with random locks put here and there.

> > > If you don't like it, the only way will be to offload to a dedicated
> > > kernel thread (like the OOM reaper) so that allocating threads are
> > > no longer blocked by oom_lock. That's a big change.
> > 
> > This doesn't solve anything as all the tasks would have to somehow wait
> > for the kernel thread to do its stuff.
> 
> Which direction are you looking at?

I am sorry but I would only repeat something that has been said many
times already. You keep hammering this particular issue like it was the
number one problem in the MM code. We have many much more important
issues to deal with. While it is interesting to make kernel more robust
under OOM conditions it doesn't make much sense to overcomplicate the
code for unrealistic workloads. If we have problems with real life
scenarios then let's fix them, by all means.
-- 
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>