linux-kernel - Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

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: <20180608102446.GE658@localhost.localdomain>
Date:   Fri, 8 Jun 2018 12:24:46 +0200
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Quentin Perret <quentin.perret@....com>
Cc:     peterz@...radead.org, rjw@...ysocki.net,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org, mingo@...hat.com,
        dietmar.eggemann@....com, morten.rasmussen@....com,
        chris.redpath@....com, patrick.bellasi@....com,
        valentin.schneider@....com, vincent.guittot@...aro.org,
        thara.gopinath@...aro.org, viresh.kumar@...aro.org,
        tkjos@...gle.com, joelaf@...gle.com, smuckle@...gle.com,
        adharmap@...cinc.com, skannan@...cinc.com, pkondeti@...eaurora.org,
        edubezval@...il.com, srinivas.pandruvada@...ux.intel.com,
        currojerez@...eup.net, javi.merino@...nel.org
Subject: Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU
 on task wake-up

Hi,

On 21/05/18 15:25, Quentin Perret wrote:

[...]

> +static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> +{
> +	unsigned long cur_energy, prev_energy, best_energy, cpu_cap, task_util;
> +	int cpu, best_energy_cpu = prev_cpu;
> +	struct sched_energy_fd *sfd;
> +	struct sched_domain *sd;
> +
> +	sync_entity_load_avg(&p->se);
> +
> +	task_util = task_util_est(p);
> +	if (!task_util)
> +		return prev_cpu;
> +
> +	/*
> +	 * Energy-aware wake-up happens on the lowest sched_domain starting
> +	 * from sd_ea spanning over this_cpu and prev_cpu.
> +	 */
> +	sd = rcu_dereference(*this_cpu_ptr(&sd_ea));
> +	while (sd && !cpumask_test_cpu(prev_cpu, sched_domain_span(sd)))
> +		sd = sd->parent;
> +	if (!sd)
> +		return -1;

Shouldn't this be return prev_cpu?

> +
> +	if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed))
> +		prev_energy = best_energy = compute_energy(p, prev_cpu);
> +	else
> +		prev_energy = best_energy = ULONG_MAX;
> +
> +	for_each_freq_domain(sfd) {
> +		unsigned long spare_cap, max_spare_cap = 0;
> +		int max_spare_cap_cpu = -1;
> +		unsigned long util;
> +
> +		/* Find the CPU with the max spare cap in the freq. dom. */

I undestand this being a heuristic to cut some overhead, but shouldn't
the model tell between packing vs. spreading?

Thanks,

 -Juri