From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] mm, page_alloc: actually ignore mempolicies for high priority allocations
Date: Sat, 18 Aug 2018 22:02:14 +0900 [thread overview]
Message-ID: <6680ec46-8a73-bc70-5dff-eb3cf49482a2@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20180816100317.GV32645@dhcp22.suse.cz>
On 2018/08/16 19:03, Michal Hocko wrote:
> The code is quite subtle and we have a bad history of copying stuff
> without rethinking whether the code still is needed. Which is sad and a
> clear sign that the code is too complex. I cannot say this change
> doesn't have any subtle side effects but it makes the intention clear at
> least so I _think_ it is good to go. If we find some unintended side
> effects we should simply rethink the whole reset zonelist thing.
Does this change affect
/*
* This is not a __GFP_THISNODE allocation, so a truncated nodemask in
* the page allocator means a mempolicy is in effect. Cpuset policy
* is enforced in get_page_from_freelist().
*/
if (oc->nodemask &&
!nodes_subset(node_states[N_MEMORY], *oc->nodemask)) {
oc->totalpages = total_swap_pages;
for_each_node_mask(nid, *oc->nodemask)
oc->totalpages += node_spanned_pages(nid);
return CONSTRAINT_MEMORY_POLICY;
}
in constrained_alloc() called from
/*
* Check if there were limitations on the allocation (only relevant for
* NUMA and memcg) that may require different handling.
*/
constraint = constrained_alloc(oc);
if (constraint != CONSTRAINT_MEMORY_POLICY)
oc->nodemask = NULL;
in out_of_memory() ?
next prev parent reply other threads:[~2018-08-18 13:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180612122624.8045-1-vbabka@suse.cz>
2018-08-15 22:16 ` Andrew Morton
2018-08-16 9:25 ` Mel Gorman
2018-08-16 10:03 ` Michal Hocko
2018-08-18 13:02 ` Tetsuo Handa [this message]
2018-08-20 10:41 ` Michal Hocko
2018-08-20 10:52 ` Tetsuo Handa
2018-08-20 11:04 ` 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=6680ec46-8a73-bc70-5dff-eb3cf49482a2@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox