On 07/27/2015 05:39 PM, Johannes Weiner wrote:
On Fri, Jul 24, 2015 at 04:45:23PM +0200, Vlastimil Babka wrote:@@ -310,11 +326,18 @@ static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask, return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask)); } +/* + * Allocate pages, restricting the allocation to the node given as nid. The + * node must be valid and online. This is achieved by adding __GFP_THISNODE + * to gfp_mask. + */ static inline struct page *alloc_pages_exact_node(int nid, gfp_t gfp_mask, unsigned int order) { VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid)); + gfp_mask |= __GFP_THISNODE; + return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask)); }The "exact" name is currently ambiguous within the allocator API, and it's bad that we have _exact_node() and _exact_nid() with entirely different meanings. It'd be good to make "thisnode" refer to specific and exclusive node requests, and "exact" to mean page allocation chunks that are not in powers of two.
Ugh, good point.
Would you consider renaming this function to alloc_pages_thisnode() as part of this series?
Sure, let's do it properly while at it. Yet "thisnode" is somewhat misleading name as it might imply the cpu's local node. The same applies to __GFP_THISNODE. So maybe find a better name for both? restrict_node? single_node?
-- 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>