Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1531672

Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE

From Dave Hansen <dave.hansen@intel.com>
Newsgroups linux.kernel
Subject Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has __GFP_THISNODE
Date 2016-11-28 22:20 +0100
Message-ID <sIBvb-7oU-31@gated-at.bofh.it> (permalink)
References <sGkf7-8lc-3@gated-at.bofh.it> <sGkf7-8lc-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 11/22/2016 06:19 AM, Anshuman Khandual wrote:
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3715,7 +3715,7 @@ struct page *
>  		.migratetype = gfpflags_to_migratetype(gfp_mask),
>  	};
>  
> -	if (cpusets_enabled()) {
> +	if (cpusets_enabled() && !(alloc_mask & __GFP_THISNODE)) {
>  		alloc_mask |= __GFP_HARDWALL;
>  		alloc_flags |= ALLOC_CPUSET;
>  		if (!ac.nodemask)

This means now that any __GFP_THISNODE allocation can "escape" the
cpuset.  That seems like a pretty major change to how cpusets works.  Do
we know that *ALL* __GFP_THISNODE allocations are truly lacking in a
cpuset context that can be enforced?

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has  __GFP_THISNODE Dave Hansen <dave.hansen@intel.com> - 2016-11-28 22:20 +0100
  Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has  __GFP_THISNODE Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2016-11-29 08:00 +0100
    Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has  __GFP_THISNODE Dave Hansen <dave.hansen@intel.com> - 2016-11-29 18:00 +0100
      Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has  __GFP_THISNODE Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2016-11-30 12:20 +0100
        Re: [RFC 4/4] mm: Ignore cpuset enforcement when allocation flag has  __GFP_THISNODE Dave Hansen <dave.hansen@intel.com> - 2016-11-30 20:50 +0100

csiph-web