From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
quentin.perret@arm.com, dietmar.eggemann@arm.com,
Morten.Rasmussen@arm.com, pauld@redhat.com
Subject: Re: [PATCH 3/5] sched/fair: rework load_balance
Date: Fri, 19 Jul 2019 14:54:43 +0200 [thread overview]
Message-ID: <20190719125443.GJ3419@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1563523105-24673-4-git-send-email-vincent.guittot@linaro.org>
On Fri, Jul 19, 2019 at 09:58:23AM +0200, Vincent Guittot wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 67f0acd..472959df 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5376,18 +5376,6 @@ static unsigned long capacity_of(int cpu)
> return cpu_rq(cpu)->cpu_capacity;
> }
>
> -static unsigned long cpu_avg_load_per_task(int cpu)
> -{
> - struct rq *rq = cpu_rq(cpu);
> - unsigned long nr_running = READ_ONCE(rq->cfs.h_nr_running);
> - unsigned long load_avg = cpu_runnable_load(rq);
> -
> - if (nr_running)
> - return load_avg / nr_running;
> -
> - return 0;
> -}
> -
> static void record_wakee(struct task_struct *p)
> {
> /*
> @@ -7646,7 +7669,6 @@ static unsigned long task_h_load(struct task_struct *p)
> struct sg_lb_stats {
> unsigned long avg_load; /*Avg load across the CPUs of the group */
> unsigned long group_load; /* Total load over the CPUs of the group */
> - unsigned long load_per_task;
> unsigned long group_capacity;
> unsigned long group_util; /* Total utilization of the group */
> unsigned int sum_nr_running; /* Nr tasks running in the group */
> @@ -8266,76 +8293,6 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
> }
>
> /**
> - * fix_small_imbalance - Calculate the minor imbalance that exists
> - * amongst the groups of a sched_domain, during
> - * load balancing.
> - * @env: The load balancing environment.
> - * @sds: Statistics of the sched_domain whose imbalance is to be calculated.
> - */
> -static inline
> -void fix_small_imbalance(struct lb_env *env, struct sd_lb_stats *sds)
> -{
> - unsigned long tmp, capa_now = 0, capa_move = 0;
> - unsigned int imbn = 2;
> - unsigned long scaled_busy_load_per_task;
> - struct sg_lb_stats *local, *busiest;
> -
> - local = &sds->local_stat;
> - busiest = &sds->busiest_stat;
> -
> - if (!local->sum_h_nr_running)
> - local->load_per_task = cpu_avg_load_per_task(env->dst_cpu);
> - else if (busiest->load_per_task > local->load_per_task)
> - imbn = 1;
> -
> - scaled_busy_load_per_task =
> - (busiest->load_per_task * SCHED_CAPACITY_SCALE) /
> - busiest->group_capacity;
> -
> - if (busiest->avg_load + scaled_busy_load_per_task >=
> - local->avg_load + (scaled_busy_load_per_task * imbn)) {
> - env->imbalance = busiest->load_per_task;
> - return;
> - }
> -
> - /*
> - * OK, we don't have enough imbalance to justify moving tasks,
> - * however we may be able to increase total CPU capacity used by
> - * moving them.
> - */
> -
> - capa_now += busiest->group_capacity *
> - min(busiest->load_per_task, busiest->avg_load);
> - capa_now += local->group_capacity *
> - min(local->load_per_task, local->avg_load);
> - capa_now /= SCHED_CAPACITY_SCALE;
> -
> - /* Amount of load we'd subtract */
> - if (busiest->avg_load > scaled_busy_load_per_task) {
> - capa_move += busiest->group_capacity *
> - min(busiest->load_per_task,
> - busiest->avg_load - scaled_busy_load_per_task);
> - }
> -
> - /* Amount of load we'd add */
> - if (busiest->avg_load * busiest->group_capacity <
> - busiest->load_per_task * SCHED_CAPACITY_SCALE) {
> - tmp = (busiest->avg_load * busiest->group_capacity) /
> - local->group_capacity;
> - } else {
> - tmp = (busiest->load_per_task * SCHED_CAPACITY_SCALE) /
> - local->group_capacity;
> - }
> - capa_move += local->group_capacity *
> - min(local->load_per_task, local->avg_load + tmp);
> - capa_move /= SCHED_CAPACITY_SCALE;
> -
> - /* Move if we gain throughput */
> - if (capa_move > capa_now)
> - env->imbalance = busiest->load_per_task;
> -}
> -
> -/**
> * calculate_imbalance - Calculate the amount of imbalance present within the
> * groups of a given sched_domain during load balance.
> * @env: load balance environment
Maybe strip this out first, in a separate patch. It's all magic doo-doo.
next prev parent reply other threads:[~2019-07-19 12:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 7:58 [PATCH 0/5] sched/fair: rework the CFS load balance Vincent Guittot
2019-07-19 7:58 ` [PATCH 1/5] sched/fair: clean up asym packing Vincent Guittot
2019-07-19 7:58 ` [PATCH 2/5] sched/fair: rename sum_nr_running to sum_h_nr_running Vincent Guittot
2019-07-19 12:51 ` Peter Zijlstra
2019-07-19 13:44 ` Vincent Guittot
2019-07-26 2:17 ` Srikar Dronamraju
2019-07-26 8:41 ` Vincent Guittot
2019-07-19 7:58 ` [PATCH 3/5] sched/fair: rework load_balance Vincent Guittot
2019-07-19 12:52 ` Peter Zijlstra
2019-07-19 13:46 ` Vincent Guittot
2019-07-19 12:54 ` Peter Zijlstra [this message]
2019-07-19 14:02 ` Vincent Guittot
2019-07-20 11:31 ` Peter Zijlstra
2019-07-19 13:06 ` Peter Zijlstra
2019-07-19 13:57 ` Vincent Guittot
2019-07-19 13:12 ` Peter Zijlstra
2019-07-19 14:13 ` Vincent Guittot
2019-07-19 13:22 ` Peter Zijlstra
2019-07-19 13:55 ` Vincent Guittot
2019-07-25 17:17 ` Valentin Schneider
2019-07-26 9:01 ` Vincent Guittot
2019-07-26 10:41 ` Valentin Schneider
2019-07-26 12:30 ` Vincent Guittot
2019-07-26 14:01 ` Valentin Schneider
2019-07-26 14:47 ` Vincent Guittot
2019-07-29 14:28 ` Valentin Schneider
2019-07-26 13:58 ` Srikar Dronamraju
2019-07-26 14:09 ` Valentin Schneider
2019-07-26 14:42 ` Vincent Guittot
2019-07-31 13:43 ` Srikar Dronamraju
2019-07-31 15:37 ` Vincent Guittot
2019-07-19 7:58 ` [PATCH 4/5] sched/fair: use load instead of runnable load Vincent Guittot
2019-07-19 7:58 ` [PATCH 5/5] sched/fair: evenly spread tasks when not overloaded Vincent Guittot
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=20190719125443.GJ3419@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Morten.Rasmussen@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=quentin.perret@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
Powered by JetHome