Michal Hocko wrote:
> On Wed 23-05-18 19:24:48, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > > I don't understand why you are talking about PF_WQ_WORKER case.
> > >
> > > Because that seems to be the reason to have it there as per your
> > > comment.
> >
> > OK. Then, I will fold below change into my patch.
> >
> > if (did_some_progress) {
> > no_progress_loops = 0;
> > + /*
> > -+ * This schedule_timeout_*() serves as a guaranteed sleep for
> > -+ * PF_WQ_WORKER threads when __zone_watermark_ok() == false.
> > ++ * Try to give the OOM killer/reaper/victims some time for
> > ++ * releasing memory.
> > + */
> > + if (!tsk_is_oom_victim(current))
> > + schedule_timeout_uninterruptible(1);
>
> Do you really need this? You are still fiddling with this path at all? I
> see how removing the timeout might be reasonable after recent changes
> but why do you insist in adding it outside of the lock.
Sigh... We can't remove this sleep without further changes. That's why I added
* This schedule_timeout_*() serves as a guaranteed sleep for
* PF_WQ_WORKER threads when __zone_watermark_ok() == false.
so that we won't by error remove this sleep without further changes.
This sleep is not only for waiting for OOM victims. Any thread who is holding
oom_lock needs CPU resources in order to make forward progress.
If oom_notify_list callbacks are registered, this sleep helps the owner of
oom_lock to reclaim memory by processing the callbacks.
If oom_notify_list callbacks did not release memory, this sleep still helps
the owner of oom_lock to check whether there is inflight OOM victims.
If there is no inflight OOM victims, this sleep still helps the owner of
oom_lock to select a new OOM victim and call printk().
If there are already inflight OOM victims, this sleep still helps the OOM
reaper and the OOM victims to release memory.
Printing messages to consoles and reclaiming memory need CPU resources.
More reliable way is to use mutex_lock_killable(&oom_lock) instead of
mutex_trylock(&oom_lock) in __alloc_pages_may_oom(), but I'm giving way
for now. There is no valid reason for removing this sleep now.
