Re: [PATCH v2 18/19] sched/numa: Reset scan rate whenever task moves across nodes

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

> We talked about this before but I would at least suggest that you not
> reset the scan if moving to the preferred node or if the node movement
> has nothing to do with the preferred nid. e.g.
> 

I understand your concern and okay to drop this patch for now.
I will try to rework and come back later.

> 	/*
> 	 * Ignore if the migration is not changing node, if it is migrating to
> 	 * the preferred node or moving between two nodes that are not preferred
> 	 */
> 
> 	if (p->numa_faults) {
> 		int src_nid = cpu_to_node(task_cpu(p));
> 		int dst_nid = cpu_to_node(new_cpu);
> 
> 		if (src_nid == dst_nid || dst_nid == p->numa_preferred_nid ||
> 		    (p->numa_preferred_nid != -1 && src_nid != p->numa_preferred_nid))

With out this change/patch, we used to reduce our scan rate whenever numa
balancer moved a task to a preferred node. This was made to verify that
the task movement was correct. The check ( dst_nid == p->numa_preferred_nid)
will negate that verification. I thought the whole point of reducing the
scan period was to correct if we choose a wrong node.

> 			return;
> 
> 		p->numa_scan_period = task_scan_start(p);
> 
> Note too that the next scan can be an arbitrary amount of time in the
> future. Consider as an alternative to schedule an immediate scan instead
> of adjusting the rate with
> 
> 		p->mm->numa_next_scan = jiffies;
> 

I will try to work along these lines.  Though the scan happens
immediately the task placement will not happen immediately so I am not
sure if it would help much.

> That might be less harmful in terms of overhead while still collecting
> some data in the short-term.
> 

-- 
Thanks and Regards
Srikar