public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vincent.donnefort@arm.com>
To: Chitti Babu Theegala <quic_ctheegal@quicinc.com>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, joel@joelfernandes.org,
	linux-arm-msm@vger.kernel.org, quic_lingutla@quicinc.com,
	linux-kernel@vger.kernel.org, quic_rjendra@quicinc.com
Subject: Re: [PATCH] sched/fair: Prefer small idle cores for forkees
Date: Thu, 13 Jan 2022 16:35:29 +0000	[thread overview]
Message-ID: <YeBRD9zKSLPBFX+j@FVFF7649Q05P> (raw)
In-Reply-To: <20220112143902.13239-1-quic_ctheegal@quicinc.com>

On Wed, Jan 12, 2022 at 08:09:02PM +0530, Chitti Babu Theegala wrote:
> Newly forked threads don't have any useful utilization data yet and
> it's not possible to forecast their impact on energy consumption.
>update_pick_idlest These forkees (though very small, most times) end up waking big
> cores from deep sleep for that very small durations.
> 
> Bias all forkees to small cores to prevent waking big cores from deep
> sleep to save power.

This bias might be interesting for some workloads, but what about the
others? (see find_energy_efficient_cpu() comment, which discusses forkees).

> 
> Signed-off-by: Chitti Babu Theegala <quic_ctheegal@quicinc.com>
> ---
>  kernel/sched/fair.c | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6e476f6..d407bbc 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5976,7 +5976,7 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p,
>  }
>  
>  static struct sched_group *
> -find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu);
> +find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu, int sd_flag);
>  
>  /*
>   * find_idlest_group_cpu - find the idlest CPU among the CPUs in the group.
> @@ -6063,7 +6063,7 @@ static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p
>  			continue;
>  		}
>  
> -		group = find_idlest_group(sd, p, cpu);
> +		group = find_idlest_group(sd, p, cpu, sd_flag);
>  		if (!group) {
>  			sd = sd->child;
>  			continue;
> @@ -8997,7 +8997,8 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd,
>  static bool update_pick_idlest(struct sched_group *idlest,
>  			       struct sg_lb_stats *idlest_sgs,
>  			       struct sched_group *group,
> -			       struct sg_lb_stats *sgs)
> +			       struct sg_lb_stats *sgs,
> +			       int sd_flag)
>  {
>  	if (sgs->group_type < idlest_sgs->group_type)
>  		return true;
> @@ -9034,6 +9035,11 @@ static bool update_pick_idlest(struct sched_group *idlest,
>  		if (idlest_sgs->idle_cpus > sgs->idle_cpus)
>  			return false;
>  
> +		/* Select smaller cpu group for newly woken up forkees */
> +		if ((sd_flag & SD_BALANCE_FORK) && (idlest_sgs->idle_cpus &&
> +			!capacity_greater(idlest->sgc->max_capacity, group->sgc->max_capacity)))
> +			return false;
> +

Energy biased placement should probably be applied only when EAS is enabled.

It's especially true here, if all CPUs have the same capacity, capacity_greater
would be always false. So unless I missed something, we wouldn't let the group_util
evaluation happen, would we?

[...]

  reply	other threads:[~2022-01-13 16:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 14:39 [PATCH] sched/fair: Prefer small idle cores for forkees Chitti Babu Theegala
2022-01-13 16:35 ` Vincent Donnefort [this message]
2022-01-20 16:45   ` Chitti Babu Theegala
2022-01-21 10:17     ` Vincent Donnefort
2022-01-25  7:13       ` Chitti Babu Theegala

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=YeBRD9zKSLPBFX+j@FVFF7649Q05P \
    --to=vincent.donnefort@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=quic_ctheegal@quicinc.com \
    --cc=quic_lingutla@quicinc.com \
    --cc=quic_rjendra@quicinc.com \
    --cc=rostedt@goodmis.org \
    --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