Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1531672
| 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 |
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 | Next — Next in thread | Find similar | Unroll 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