Michal Hocko wrote:
> On Tue 26-04-16 23:00:15, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > Hmm, I guess we have already discussed that in the past but I might
> > > misremember. The above relies on oom killer to be triggered after the
> > > previous victim was selected. There is no guarantee this will happen.
> >
> > Why there is no guarantee this will happen?
>
> What happens if you even do not hit the out_of_memory path? E.g
> GFP_FS allocation being stuck somewhere in shrinkers waiting for
> somebody to make a forward progress which never happens. Because this is
> essentially what would block the mmap_sem write holder as well and what
> you are trying to workaround by the timeout based approach.
>
Are you talking about situations where the system hangs up before
mark_oom_victim() is called? If yes, starting a timer from mark_oom_victim()
is too late. We will need to start that timer from __alloc_pages_slowpath()
because __alloc_pages_slowpath() can sleep. Then, we don't need to consider
"OOM livelock before mark_oom_victim() is called" and "OOM livelock after
mark_oom_victim() is called" separately.
> > These OOM livelocks are caused by lack of mechanism for hearing administrator's
> > policy. We are missing rescue mechanisms which are needed for recovering from
> > situations your model did not expect.
>
> I am not opposed against a rescue policy defined by the admin. All I
> am saying is that the only save and reasonably maintainable one with
> _predictable_ behavior I can see is to reboot/panic/killall-tasks after
> a certain timeout. You consider this to be too harsh but do you at
> least agree that the semantic of this is clear and an admin knows what
> the behavior would be? As we are not able to find a consensus on
> go-to-other-victim approach can we at least agree on the absolute last
> resort first?
>
Which one ("OOM livelock before mark_oom_victim() is called" or "OOM livelock
after mark_oom_victim() is called") does this "the absolute last resort" apply to?
If this "the absolute last resort" applies to "OOM livelock after mark_oom_victim()
is called", what is your "the absolute last resort" for "OOM livelock before
mark_oom_victim() is called"? My suggestion is to workaround by per task_struct
timeout based approach until such workaround becomes no longer needed.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>