On Mon 21-05-18 00:56:05, Tetsuo Handa wrote:
> 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.
Because that seems to be the reason to have it there as per your
comment.
> 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.
And now you have made the comment misleading and I suspect it is just
not really needed as well.
> 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.
You are fiddling with other code paths at the same time so I _do_ care.
Spilling random code without a proper explanation is just not going to
fly.
--
Michal Hocko
SUSE Labs
