Re: [PATCH] mm,oom: Re-enable OOM killer using timeout.

[Michal Hocko <mhocko@kernel.org>]

On Wed 20-04-16 06:55:42, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > This patch adds a timeout for handling corner cases where a TIF_MEMDIE
> > > thread got stuck. Since the timeout is checked at oom_unkillable_task(),
> > > oom_scan_process_thread() will not find TIF_MEMDIE thread
> > > (for !oom_kill_allocating_task case) and oom_badness() will return 0
> > > (for oom_kill_allocating_task case).
> > > 
> > > By applying this patch, the kernel will automatically press SysRq-f if
> > > the OOM reaper cannot reap the victim's memory, and we will never OOM
> > > livelock forever as long as the OOM killer is called.
> > 
> > Which will not guarantee anything as already pointed out several times
> > before. So I think this is not really that useful. I have said it
> > earlier and will repeat it again. Any timeout based solution which
> > doesn't guarantee that the system will be in a consistent state (reboot,
> > panic or kill all existing tasks) after the specified timeout is
> > pointless.
> 
> Triggering the reboot/panic is the worst action. Killing all existing tasks
> is the next worst action. Thus, I prefer killing tasks one by one.

killing a task by task doesn't guarantee any convergence to a usable
state. If somebody really cares about these highly unlikely lockups
I am pretty sure he would really appreciate to have a _reliable_ and
_guaranteed_ way out of that situation. Having a fuzzy mechanism to do
something in a good hope of resolving that state is just unhelpful.

If I was an admin and had a machine on the other side of the globe and
that machine just locked up due to OOM I would pretty much wanted to
force reboot as my other means of fixing that situation would be pretty
much close to zero otherwise.

> I'm OK with shortening the timeout like N (when waiting for the 1st victim)
> + N/2 (the 2nd victim) + N/4 (the 3rd victim) + N/8 (the 4th victim) + ...
> but does it worth complicating the least unlikely path?

No it is not IMHO.
 
> > I believe that the chances of the lockup are much less likely with the
> > oom reaper and that we are not really urged to provide a new knob with a
> > random semantic. If we really want to have a timeout based thing better
> > make it behave reliably.
> 
> The threshold which the administrator can wait for ranges. Some may want to
> set few seconds because of 10 seconds /dev/watchdog timeout, others may want
> to set one minute because of not using watchdog. Thus, I think we should not
> hard code the timeout.

I guess you missed my point here. I didn't say this should be hardcoded
in any way. I am just saying that if we really want to do some timeout
based decisions we should better think about the semantic and that
should provide a reliable and deterministic means to resolve the problem.

-- 
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>