linux-kernel - Re: [RFC PATCH 4/7] sched/fair: Dissociate wakeup decisions from SD flag value

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:   Wed, 11 Dec 2019 16:53:22 +0000
From:   Valentin Schneider <valentin.schneider@....com>
To:     linux-kernel@...r.kernel.org
Cc:     mingo@...hat.com, peterz@...radead.org, vincent.guittot@...aro.org,
        dietmar.eggemann@....com
Subject: Re: [RFC PATCH 4/7] sched/fair: Dissociate wakeup decisions from SD
 flag value

On 11/12/2019 16:43, Valentin Schneider wrote:
> @@ -6396,9 +6396,8 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
>  	if (unlikely(sd)) {
>  		/* Slow path */
>  		new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
> -	} else if (sd_flag & SD_BALANCE_WAKE) { /* XXX always ? */
> +	} else if (wake_flags & WF_TTWU) { /* XXX always ? */

While I'm at it, Dietmar pointed out to me that this is only really
relevant to forkees and execees when a NULL domain is attached to the CPU
(since sd_init() unconditionally sets SD_BALANCE_{FORK, EXEC}). So this
only makes a difference when the SD hierarchy hasn't been built / is being
rebuilt, or when cpusets are involved.

So perhaps we could make that an unconditional else, or make forkees/execees
bail out earlier.

>  		/* Fast path */
> -
>  		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
>  
>  		if (want_affine)
>