All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Feng Tang <feng.tang@intel.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Ben Widawsky <ben.widawsky@intel.com>,
	linux-kernel@vger.kernel.org,
	Andrea Arcangeli <aarcange@redhat.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>, Andi Kleen <ak@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	ying.huang@intel.com
Subject: Re: [v3 PATCH 1/3] mm/mempolicy: cleanup nodemask intersection check for oom
Date: Tue, 1 Jun 2021 10:19:25 +0200	[thread overview]
Message-ID: <YLXtjRYUcaXcYfua@dhcp22.suse.cz> (raw)
In-Reply-To: <1622469956-82897-2-git-send-email-feng.tang@intel.com>

On Mon 31-05-21 22:05:54, Feng Tang wrote:
> mempolicy_nodemask_intersects() is used in oom case to check if a
> task may have memory allocated on some memory nodes.
> 
> As it's only used by OOM check, rename it to mempolicy_in_oom_domain()
> to reduce confusion.
> 
> As only for 'bind' policy, the nodemask is a force requirement for
> from where to allocate memory, only do the intesection check for it,
> and return true for all other policies.

I would slightly rephrase the above to
"
mempolicy_nodemask_intersects seem to be a general purpose mempolicy
function. In fact it is partially tailored for the OOM purpose instead.
The oom proper is the only existing user so rename the function to make
that purpose explicit.

While at it drop the MPOL_INTERLEAVE as those allocations never has a
nodemask defined (see alloc_page_interleave) so this is a dead code
and a confusing one because MPOL_INTERLEAVE is a hint rather than a hard
requirement so it shouldn't be considered during the OOM.

The final code can be reduced to a check for MPOL_BIND which is the only
memory policy that is a hard requirement and thus relevant to a
constrained OOM logic.
"

> Suggested-by: Michal Hocko <mhocko@suse.com>
> Signed-off-by: Feng Tang <feng.tang@intel.com>

To the change itself
Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  include/linux/mempolicy.h |  2 +-
>  mm/mempolicy.c            | 34 +++++++++-------------------------
>  mm/oom_kill.c             |  2 +-
>  3 files changed, 11 insertions(+), 27 deletions(-)
> 
> diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
> index 5f1c74d..8773c55 100644
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -150,7 +150,7 @@ extern int huge_node(struct vm_area_struct *vma,
>  				unsigned long addr, gfp_t gfp_flags,
>  				struct mempolicy **mpol, nodemask_t **nodemask);
>  extern bool init_nodemask_of_mempolicy(nodemask_t *mask);
> -extern bool mempolicy_nodemask_intersects(struct task_struct *tsk,
> +extern bool mempolicy_in_oom_domain(struct task_struct *tsk,
>  				const nodemask_t *mask);
>  extern nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *policy);
>  
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index d79fa29..6795a6a 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2094,16 +2094,16 @@ bool init_nodemask_of_mempolicy(nodemask_t *mask)
>  #endif
>  
>  /*
> - * mempolicy_nodemask_intersects
> + * mempolicy_in_oom_domain
>   *
> - * If tsk's mempolicy is "default" [NULL], return 'true' to indicate default
> - * policy.  Otherwise, check for intersection between mask and the policy
> - * nodemask for 'bind' or 'interleave' policy.  For 'preferred' or 'local'
> - * policy, always return true since it may allocate elsewhere on fallback.
> + * If tsk's mempolicy is "bind", check for intersection between mask and
> + * the policy nodemask. Otherwise, return true for all other policies
> + * including "interleave", as a tsk with "interleave" policy may have
> + * memory allocated from all nodes in system.
>   *
>   * Takes task_lock(tsk) to prevent freeing of its mempolicy.
>   */
> -bool mempolicy_nodemask_intersects(struct task_struct *tsk,
> +bool mempolicy_in_oom_domain(struct task_struct *tsk,
>  					const nodemask_t *mask)
>  {
>  	struct mempolicy *mempolicy;
> @@ -2111,29 +2111,13 @@ bool mempolicy_nodemask_intersects(struct task_struct *tsk,
>  
>  	if (!mask)
>  		return ret;
> +
>  	task_lock(tsk);
>  	mempolicy = tsk->mempolicy;
> -	if (!mempolicy)
> -		goto out;
> -
> -	switch (mempolicy->mode) {
> -	case MPOL_PREFERRED:
> -		/*
> -		 * MPOL_PREFERRED and MPOL_F_LOCAL are only preferred nodes to
> -		 * allocate from, they may fallback to other nodes when oom.
> -		 * Thus, it's possible for tsk to have allocated memory from
> -		 * nodes in mask.
> -		 */
> -		break;
> -	case MPOL_BIND:
> -	case MPOL_INTERLEAVE:
> +	if (mempolicy && mempolicy->mode == MPOL_BIND)
>  		ret = nodes_intersects(mempolicy->v.nodes, *mask);
> -		break;
> -	default:
> -		BUG();
> -	}
> -out:
>  	task_unlock(tsk);
> +
>  	return ret;
>  }
>  
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index eefd3f5..fcc29e9 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -104,7 +104,7 @@ static bool oom_cpuset_eligible(struct task_struct *start,
>  			 * mempolicy intersects current, otherwise it may be
>  			 * needlessly killed.
>  			 */
> -			ret = mempolicy_nodemask_intersects(tsk, mask);
> +			ret = mempolicy_in_oom_domain(tsk, mask);
>  		} else {
>  			/*
>  			 * This is not a mempolicy constrained oom, so only
> -- 
> 2.7.4

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2021-06-01  8:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31 14:05 [v3 PATCH 0/3] mm/mempolicy: some fix and semantics cleanup Feng Tang
2021-05-31 14:05 ` [v3 PATCH 1/3] mm/mempolicy: cleanup nodemask intersection check for oom Feng Tang
2021-06-01  8:19   ` Michal Hocko [this message]
2021-06-01 11:08     ` Feng Tang
2021-06-01 23:56       ` Andrew Morton
2021-05-31 14:05 ` [v3 PATCH 2/3] mm/mempolicy: don't handle MPOL_LOCAL like a fake MPOL_PREFERRED policy Feng Tang
2021-06-01  8:44   ` Michal Hocko
2021-06-01 11:29     ` Feng Tang
2021-05-31 14:05 ` [v3 PATCH 3/3] mm/mempolicy: unify the parameter sanity check for mbind and set_mempolicy Feng Tang
2021-06-01  8:46   ` Michal Hocko
2021-05-31 21:41 ` [v3 PATCH 0/3] mm/mempolicy: some fix and semantics cleanup Andrew Morton
2021-06-01  0:55   ` Feng Tang
2021-06-01  8:48     ` Michal Hocko

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=YLXtjRYUcaXcYfua@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben.widawsky@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=feng.tang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mike.kravetz@oracle.com \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=ying.huang@intel.com \
    /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.