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:   Thu, 13 Jan 2022 16:35:29 +0000
From:   Vincent Donnefort <vincent.donnefort@....com>
To:     Chitti Babu Theegala <quic_ctheegal@...cinc.com>
Cc:     mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, joel@...lfernandes.org,
        linux-arm-msm@...r.kernel.org, quic_lingutla@...cinc.com,
        linux-kernel@...r.kernel.org, quic_rjendra@...cinc.com
Subject: Re: [PATCH] sched/fair: Prefer small idle cores for forkees

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@...cinc.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?

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ