[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20181018191147.33e8d5e1ebd785c06aab7b30@linux-foundation.org>
Date: Thu, 18 Oct 2018 19:11:47 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
Mel Gorman <mgorman@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
David Rientjes <rientjes@...gle.com>,
Andrea Argangeli <andrea@...nel.org>,
Zi Yan <zi.yan@...rutgers.edu>,
Stefan Priebe - Profihost AG <s.priebe@...fihost.ag>,
linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] mm, thp: consolidate THP gfp handling into
alloc_hugepage_direct_gfpmask
On Wed, 26 Sep 2018 16:22:27 +0200 Michal Hocko <mhocko@...nel.org> wrote:
> > MPOL_PREFERRED is handled by policy_node() before we call __alloc_pages_nodemask.
> > __GFP_THISNODE is applied only when we are not using
> > __GFP_DIRECT_RECLAIM which is handled in alloc_hugepage_direct_gfpmask
> > now.
> > Lastly MPOL_BIND wasn't handled explicitly but in the end the removed
> > late check would remove __GFP_THISNODE for it as well. So in the end we
> > are doing the same thing unless I miss something
>
> Forgot to add. One notable exception would be that the previous code
> would allow to hit
> WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));
> in policy_node if the requested node (e.g. cpu local one) was outside of
> the mbind nodemask. This is not possible now. We haven't heard about any
> such warning yet so it is unlikely that it happens though.
Perhaps a changelog addition is needed to cover the above?
I assume that David's mbind() concern has gone away.
No acks or reviewed-by's yet?
Powered by blists - more mailing lists