lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 9 Jul 2015 12:27:46 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Rik van Riel <riel@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH] sched/numa: Restore sched feature NUMA to its earlier
 avatar.

> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ