Michal Hocko wrote:
> On Fri 18-05-18 19:14:12, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Sat 12-05-18 23:18:24, Tetsuo Handa wrote:
> > > [...]
> > > > @@ -4241,6 +4240,12 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> > > > /* Retry as long as the OOM killer is making progress */
> > > > 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.
> > > > + */
> > > > + if (!tsk_is_oom_victim(current))
> > > > + schedule_timeout_uninterruptible(1);
> > > > goto retry;
> > >
> > > We already do have that sleep for PF_WQ_WORKER in should_reclaim_retry.
> > > Why do we need it here as well?
> >
> > Because that path depends on __zone_watermark_ok() == true which is not
> > guaranteed to be executed.
>
> Is there any reason we cannot do the special cased sleep for
> PF_WQ_WORKER in should_reclaim_retry? The current code is complex enough
> to make it even more so. If we need a hack for PF_WQ_WORKER case then we
> definitely want to have a single place to do so.
I don't understand why you are talking about PF_WQ_WORKER case.
This sleep is not only for PF_WQ_WORKER case but also !PF_KTHREAD case.
I added this comment because you suggested simply removing any sleep which
waits for the OOM victim.
Making special cased sleep for PF_WQ_WORKER in should_reclaim_retry() cannot
become a reason to block this patch. You can propose it after this patch is
applied. This patch is for mitigating lockup problem caused by forever holding
oom_lock.
