On Fri, Aug 18, 2017 at 5:23 AM, Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote:
>
> new_page = alloc_pages_node(node,
> - (GFP_TRANSHUGE_LIGHT | __GFP_THISNODE),
> + (GFP_TRANSHUGE_LIGHT | __GFP_THISNODE) & ~__GFP_DIRECT_RECLAIM,
> HPAGE_PMD_ORDER);
That can't make any difference. We already have:
#define GFP_TRANSHUGE_LIGHT ((GFP_HIGHUSER_MOVABLE | __GFP_COMP | \
__GFP_NOMEMALLOC | __GFP_NOWARN) & ~__GFP_RECLAIM)
and that "& ~__GFP_RECLAIM" is removing __GFP_DIRECT_RECLAIM.
So that patch is a no-op, afaik.
Is there something else expensive in there?
It *might* be simply that we have a shit-ton of threads, and the
thread that holds the page lock for migration is just preempted out.
even if it doesn't really do anything particularly expensive.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
