lkml.org 
[lkml]   [2018]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2018-07-04 13:20    [W:0.072 / U:1.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site