All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, aarcange@redhat.com,
	hannes@cmpxchg.org
Subject: Re: [PATCH] mm,page_alloc: Update comment for last second allocation attempt.
Date: Fri, 3 Nov 2017 15:17:03 +0100	[thread overview]
Message-ID: <20171103141703.lgke7jetrjelydd3@dhcp22.suse.cz> (raw)
In-Reply-To: <201711032308.GHE78150.LQOFOtVFFJMHSO@I-love.SAKURA.ne.jp>

On Fri 03-11-17 23:08:35, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 03-11-17 22:46:29, Tetsuo Handa wrote:
> > [...]
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index c274960..547e9cb 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -3312,11 +3312,10 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
> > >  	}
> > >  
> > >  	/*
> > > -	 * Go through the zonelist yet one more time, keep very high watermark
> > > -	 * here, this is only to catch a parallel oom killing, we must fail if
> > > -	 * we're still under heavy pressure. But make sure that this reclaim
> > > -	 * attempt shall not depend on __GFP_DIRECT_RECLAIM && !__GFP_NORETRY
> > > -	 * allocation which will never fail due to oom_lock already held.
> > > +	 * This allocation attempt must not depend on __GFP_DIRECT_RECLAIM &&
> > > +	 * !__GFP_NORETRY allocation which will never fail due to oom_lock
> > > +	 * already held. And since this allocation attempt does not sleep,
> > > +	 * there is no reason we must use high watermark here.
> > >  	 */
> > >  	page = get_page_from_freelist((gfp_mask | __GFP_HARDWALL) &
> > >  				      ~__GFP_DIRECT_RECLAIM, order,
> > 
> > Which patch does this depend on?
> 
> This patch is preparation for "mm,oom: Move last second allocation to inside
> the OOM killer." patch in order to use changelog close to what you suggested.
> That is, I will move this comment and get_page_from_freelist() together to
> alloc_pages_before_oomkill(), after we recorded why using ALLOC_WMARK_HIGH.

Is it really worth a separate patch, though? Aren't you overcomplicating
things again?
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, aarcange@redhat.com,
	hannes@cmpxchg.org
Subject: Re: [PATCH] mm,page_alloc: Update comment for last second allocation attempt.
Date: Fri, 3 Nov 2017 15:17:03 +0100	[thread overview]
Message-ID: <20171103141703.lgke7jetrjelydd3@dhcp22.suse.cz> (raw)
In-Reply-To: <201711032308.GHE78150.LQOFOtVFFJMHSO@I-love.SAKURA.ne.jp>

On Fri 03-11-17 23:08:35, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 03-11-17 22:46:29, Tetsuo Handa wrote:
> > [...]
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index c274960..547e9cb 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -3312,11 +3312,10 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
> > >  	}
> > >  
> > >  	/*
> > > -	 * Go through the zonelist yet one more time, keep very high watermark
> > > -	 * here, this is only to catch a parallel oom killing, we must fail if
> > > -	 * we're still under heavy pressure. But make sure that this reclaim
> > > -	 * attempt shall not depend on __GFP_DIRECT_RECLAIM && !__GFP_NORETRY
> > > -	 * allocation which will never fail due to oom_lock already held.
> > > +	 * This allocation attempt must not depend on __GFP_DIRECT_RECLAIM &&
> > > +	 * !__GFP_NORETRY allocation which will never fail due to oom_lock
> > > +	 * already held. And since this allocation attempt does not sleep,
> > > +	 * there is no reason we must use high watermark here.
> > >  	 */
> > >  	page = get_page_from_freelist((gfp_mask | __GFP_HARDWALL) &
> > >  				      ~__GFP_DIRECT_RECLAIM, order,
> > 
> > Which patch does this depend on?
> 
> This patch is preparation for "mm,oom: Move last second allocation to inside
> the OOM killer." patch in order to use changelog close to what you suggested.
> That is, I will move this comment and get_page_from_freelist() together to
> alloc_pages_before_oomkill(), after we recorded why using ALLOC_WMARK_HIGH.

Is it really worth a separate patch, though? Aren't you overcomplicating
things again?
-- 
Michal Hocko
SUSE Labs

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

  reply	other threads:[~2017-11-03 14:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 11:54 [PATCH 1/2] mm,oom: Move last second allocation to inside the OOM killer Tetsuo Handa
2017-11-01 11:54 ` Tetsuo Handa
2017-11-01 11:54 ` [PATCH 2/2] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation Tetsuo Handa
2017-11-01 11:54   ` Tetsuo Handa
2017-11-01 13:58   ` Michal Hocko
2017-11-01 13:58     ` Michal Hocko
2017-11-01 15:08     ` Tetsuo Handa
2017-11-01 15:08       ` Tetsuo Handa
2017-11-01 15:16       ` Michal Hocko
2017-11-01 15:16         ` Michal Hocko
2017-11-01 13:27 ` [PATCH 1/2] mm,oom: Move last second allocation to inside the OOM killer Michal Hocko
2017-11-01 13:27   ` Michal Hocko
2017-11-02 11:15   ` Tetsuo Handa
2017-11-02 11:15     ` Tetsuo Handa
2017-11-02 11:16     ` [PATCH v2 " Tetsuo Handa
2017-11-02 11:16       ` Tetsuo Handa
2017-11-02 11:16       ` [PATCH v2 2/2] mm,oom: Use ALLOC_OOM for OOM victim's last second allocation Tetsuo Handa
2017-11-02 11:16         ` Tetsuo Handa
2017-11-02 13:14         ` Michal Hocko
2017-11-02 13:14           ` Michal Hocko
2017-11-02 13:21       ` [PATCH v2 1/2] mm,oom: Move last second allocation to inside the OOM killer Michal Hocko
2017-11-02 13:21         ` Michal Hocko
2017-11-03 13:46     ` [PATCH] mm,page_alloc: Update comment for last second allocation attempt Tetsuo Handa
2017-11-03 13:46       ` Tetsuo Handa
2017-11-03 13:57       ` Michal Hocko
2017-11-03 13:57         ` Michal Hocko
2017-11-03 14:08         ` Tetsuo Handa
2017-11-03 14:08           ` Tetsuo Handa
2017-11-03 14:17           ` Michal Hocko [this message]
2017-11-03 14:17             ` Michal Hocko
2017-11-03 14:27             ` Tetsuo Handa
2017-11-03 14:27               ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171103141703.lgke7jetrjelydd3@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.