> So I find the patch, the description and the comments in the code conflicting
> and
> confusing.
>
> The patch does this:
>
> @@ -5676,10 +5676,10 @@ static int migrate_degrades_locality(struct
> task_struct *p, struct lb_env *env)
> unsigned long src_faults, dst_faults;
> int src_nid, dst_nid;
>
> - if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> + if (!sched_feat(NUMA) || !sched_feat(NUMA_FAVOUR_HIGHER))
> return -1;
>
> - if (!sched_feat(NUMA))
> + if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> return -1;
>
> src_nid = cpu_to_node(env->src_cpu);
>
>
> while the default for 'NUMA' is 0, 'NUMA_FAVOUR_HIGHER' is 1.
>
> Which in itself is confusing: WTH do we have a generic switch called 'NUMA'
> and
> then have it disabled?
NUMA feature gets enabled on multi-node boxes because of
start_kernel() -> numa_policy_init() -> check_numabalancing_enable() ->
set_numabalancing_state() -> sched_feat_set("NUMA");
>
> Secondly, and more importantly, this patch is equivalent to adding this (for
> the
> default case):
>
> return -1;
This is true on only UMA box. On a numa box, the NUMA feature would be
enabled, so it wouldnt return -1 by default.
>
> i.e. it's in essence a revert of 8a9e62a!
>
While 8a9e62a did miss the part where we would enable NUMA on numa
boxes, this commit doesnt completely revert 8a9e62a.
> And it provides no explanation whatsoever. Why did we do the original change
> (8a9e62a) which was well argued but apparently broken in some fashion, and
> why do
> we want to change it back now?
The original change "8a9e62a" gives preference to numa hotness compared
to cache hotness. The rational being, for numa workloads tasks are
better of looking at numa convergence than be spread based on cache
hotness. migrate_swap/migrate_task_to already move tasks without
bothering about cache hotness so that convergence is achieved.
>
> I.e. this patch sucks on multiple grounds, and 8a9e62a probably sucks as
> well. And
> you added a Reviewed-by while you should have noticed at least 2-3 flaws in
> the
> patch and its approach. Not good.
>
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
