Messages in this thread | | | Date | Wed, 4 Jul 2018 04:19:13 -0700 | From | Srikar Dronamraju <> | Subject | Re: [PATCH v2 18/19] sched/numa: Reset scan rate whenever task moves across nodes |
| |
> 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
| |