linux-kernel - Re: [PATCH 2/2] sched: Actual changes after adding SCHED_SOFT_AFFINITY to make it work with the scheduler

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]

Message-ID: <20170921115219.5iwzhqgtx2fu4pj6@hirez.programming.kicks-ass.net>
Date:   Thu, 21 Sep 2017 13:52:19 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Rohit Jain <rohit.k.jain@...cle.com>
Cc:     linux-kernel@...r.kernel.org, eas-dev@...ts.linaro.org,
        mingo@...hat.com, joelaf@...gle.com
Subject: Re: [PATCH 2/2] sched: Actual changes after adding
 SCHED_SOFT_AFFINITY to make it work with the scheduler

On Tue, Sep 19, 2017 at 03:37:12PM -0700, Rohit Jain wrote:
> @@ -6019,7 +6040,8 @@ void __update_idle_core(struct rq *rq)
>  static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int target)
>  {
>  	struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
> +	struct cpumask *pcpus = this_cpu_cpumask_var_ptr(select_idle_mask);

This is broken... they're the exact _same_ variable.

> +	int core;
>  
>  	if (!static_branch_likely(&sched_smt_present))
>  		return -1;
> @@ -6028,20 +6050,21 @@ static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int
>  		return -1;
>  
>  	cpumask_and(cpus, sched_domain_span(sd), &p->cpus_allowed);
> +	cpumask_and(pcpus, cpus, &p->cpus_preferred);
> +	core = scan_cpu_mask_for_idle_cores(pcpus, target);
>  
> +	if (core >= 0)
> +		return core;
>  
> +	if (cpumask_equal(cpus, pcpus))
> +		goto out;

Therefore this _must_ be true.


Also, you're touching one of the hottest paths in the whole scheduler
for this half arsed feature, not going to happen.

You further failed to teach the actual load-balancer of this new mask,
so it will still happily move tasks around.