> 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
