Re: [RFC PATCH 2/2] mm,oom: Try last second allocation after selecting an OOM victim.

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Michal Hocko wrote:
> On Wed 25-10-17 23:58:33, Tetsuo Handa wrote:
> > I thought something like
> > 
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -3872,6 +3872,7 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> >         unsigned int stall_timeout = 10 * HZ;
> >         unsigned int cpuset_mems_cookie;
> >         int reserve_flags;
> > +       static DEFINE_MUTEX(warn_lock);
> > 
> >         /*
> >          * In the slowpath, we sanity check order to avoid ever trying to
> > @@ -4002,11 +4003,15 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> >                 goto nopage;
> > 
> >         /* Make sure we know about allocations which stall for too long */
> > -       if (time_after(jiffies, alloc_start + stall_timeout)) {
> > -               warn_alloc(gfp_mask & ~__GFP_NOWARN, ac->nodemask,
> > -                       "page allocation stalls for %ums, order:%u",
> > -                       jiffies_to_msecs(jiffies-alloc_start), order);
> > -               stall_timeout += 10 * HZ;
> > +       if (time_after(jiffies, alloc_start + stall_timeout) &&
> > +           mutex_trylock(&warn_lock)) {
> > +               if (!mutex_is_locked(&oom_lock)) {
> 
> The check for oom_lock just doesn't make any sense. The lock can be take
> at any time after the check.

The check for oom_lock is optimistic. If we go pessimistic, we will
need to use oom_printk_lock, but you don't like oom_printk_lock, do you?
Anyway, let's remove warn_alloc().

> 
> > +                       warn_alloc(gfp_mask & ~__GFP_NOWARN, ac->nodemask,
> > +                                  "page allocation stalls for %ums, order:%u",
> > +                                  jiffies_to_msecs(jiffies-alloc_start), order);
> > +                       stall_timeout += 10 * HZ;
> > +               }
> > +               mutex_unlock(&warn_lock);
> >         }
> > 
> >         /* Avoid recursion of direct reclaim */
> > 
> > for isolating the OOM killer messages and the stall warning messages (in order to
> > break continuation condition in console_unlock()), and

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