mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Donnefort <vincent.donnefort@arm.com>,
	peterz@infradead.org, mingo@redhat.com,
	vincent.guittot@linaro.org
Cc: linux-kernel@vger.kernel.org, morten.rasmussen@arm.com,
	chris.redpath@arm.com, qperret@google.com
Subject: Re: [PATCH v3 7/7] sched/fair: Remove the energy margin in feec()
Date: Tue, 22 Mar 2022 10:37:43 +0100	[thread overview]
Message-ID: <8ea80393-866e-9c31-85e9-46d738d24047@arm.com> (raw)
In-Reply-To: <20220308181957.280354-8-vincent.donnefort@arm.com>

On 08/03/2022 19:19, Vincent Donnefort wrote:

[...]

> 1. The energy estimation is not a good absolute value:
> 
> The function, compute_energy() used in feec() is a good estimation for

s/The function, compute_energy()/compute_energy() ... shorter

[...]

> util_avg represents integrates the near history for a CPU usage,

s/util_avg represents integrates/util_avg contains ?

[...]

> 2. The margin handicaps small tasks:
> 
> On a system where the workload is composed mostly of small tasks (which is
> often the case on Android), the overall energy will be high enough to
> create a margin none of those tasks can cross. e.g. On a Pixel4, a small

s/e.g.// ?

[...]

> Without a margin, we could have feared bouncing between CPUs. But running
> LISA's eas_behaviour test coverage on three different platforms (Hikey960,
> RB-5 and DB-845) showed no issue and even fixed previously known failures.

Can you be more specific what those fixes are? I think you mention (some
of) them in the cover letter. It's just that when somebody will read
this patch, once it's in, this information is not there.

You could also add
https://developer.arm.com/tools-and-software/open-source-software/linux-kernel/energy-aware-scheduling/eas-mainline-development
to the cover letter so people can get more information about those EAS
behaviour tests.

[...]

> @@ -6736,7 +6736,6 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  	struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
>  	int cpu, best_energy_cpu = prev_cpu, target = -1;

Nit-picking: IMHO, best_energy_cpu doesn't have to be initialized
anymore since we only use it now when `best_delta < prev_delta`,
hence best_energy_cpu has to be set at least once.

[...]

> @@ -6851,12 +6849,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  	}
>  	rcu_read_unlock();
>  
> -	/*
> -	 * Pick the best CPU if prev_cpu cannot be used, or if it saves at
> -	 * least 6% of the energy used by prev_cpu.
> -	 */
> -	if ((prev_delta == ULONG_MAX) ||
> -	    (prev_delta - best_delta) > ((prev_delta + base_energy) >> 4))
> +	if (best_delta < prev_delta)
>  		target = best_energy_cpu;
>  
>  	return target;

Can we now move the `unlock:` before the first rcu_read_unlock()?
All error case have best_delta and prev_delta = ULONG_MAX so we return
`target = -1` or `target = prev_cpu` correctly.

@@ -6960,17 +6960,13 @@ static int find_energy_efficient_cpu(struct
task_struct *p, int prev_cpu)
                        }
                }
        }
+unlock:
        rcu_read_unlock();
         if (best_delta < prev_delta)
                target = best_energy_cpu;
         return target;
-
-unlock:
-       rcu_read_unlock();
-
-       return target;

      reply	other threads:[~2022-03-22  9:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 18:19 [PATCH v3 0/7] feec() energy margin removal Vincent Donnefort
2022-03-08 18:19 ` [PATCH v3 1/7] sched/fair: Provide u64 read for 32-bits arch helper Vincent Donnefort
2022-03-08 18:19 ` [PATCH v3 2/7] sched/fair: Decay task PELT values during migration Vincent Donnefort
2022-03-21 17:23   ` Dietmar Eggemann
2022-03-08 18:19 ` [PATCH v3 3/7] sched, drivers: Remove max param from effective_cpu_util()/sched_cpu_util() Vincent Donnefort
2022-03-08 18:19 ` [PATCH v3 4/7] sched/fair: Rename select_idle_mask to select_rq_mask Vincent Donnefort
2022-03-08 18:19 ` [PATCH v3 5/7] sched/fair: Use the same cpumask per-PD throughout find_energy_efficient_cpu() Vincent Donnefort
2022-03-08 18:19 ` [PATCH v3 6/7] sched/fair: Remove task_util from effective utilization in feec() Vincent Donnefort
2022-03-22  9:25   ` Dietmar Eggemann
2022-03-08 18:19 ` [PATCH v3 7/7] sched/fair: Remove the energy margin " Vincent Donnefort
2022-03-22  9:37   ` Dietmar Eggemann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8ea80393-866e-9c31-85e9-46d738d24047@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=chris.redpath@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=vincent.donnefort@arm.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®