Re: [PATCH v2 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator

From: Vlastimil Babka
Date: Thu May 18 2017 - 06:25:44 EST


On 05/17/2017 05:19 PM, Christoph Lameter wrote:
> On Wed, 17 May 2017, Vlastimil Babka wrote:
>
>> struct page *
>> -__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
>> - struct zonelist *zonelist, nodemask_t *nodemask);
>> +__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
>> + nodemask_t *nodemask);
>>
>> static inline struct page *
>> -__alloc_pages(gfp_t gfp_mask, unsigned int order,
>> - struct zonelist *zonelist)
>> +__alloc_pages(gfp_t gfp_mask, unsigned int order, int preferred_nid)
>> {
>> - return __alloc_pages_nodemask(gfp_mask, order, zonelist, NULL);
>> + return __alloc_pages_nodemask(gfp_mask, order, preferred_nid, NULL);
>> }
>
> Maybe use nid instead of preferred_nid like in __alloc_pages? Otherwise
> there may be confusion with the MPOL_PREFER policy.

I'll think about that.

>> @@ -1963,8 +1960,8 @@ alloc_pages_vma(gfp_t gfp, int order, struct vm_area_struct *vma,
>> {
>> struct mempolicy *pol;
>> struct page *page;
>> + int preferred_nid;
>> unsigned int cpuset_mems_cookie;
>> - struct zonelist *zl;
>> nodemask_t *nmask;
>
> Same here.
>
>> @@ -4012,8 +4012,8 @@ static inline void finalise_ac(gfp_t gfp_mask,
>> * This is the 'heart' of the zoned buddy allocator.
>> */
>> struct page *
>> -__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
>> - struct zonelist *zonelist, nodemask_t *nodemask)
>> +__alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
>> + nodemask_t *nodemask)
>> {
>
> and here
>
> This looks clean to me. Still feel a bit uneasy about this since I do
> remember that we had a reason to use zonelists instead of nodes back then
> but cannot remember what that reason was....

My history digging showed me that mempolicies used to have a custom
zonelist attached, not nodemask. So I supposed that's why.

> CCing Dimitri at SGI. This may break a lot of legacy SGIapps. If you read
> this Dimitri then please review this patchset and the discussions around
> it.

Break how? This shouldn't break any apps AFAICS, just out-of-tree kernel
patches/modules as usual when APIs change.

> Reviewed-by: Christoph Lameter <cl@xxxxxxxxx>

Thanks!