From: Qais Yousef <qais.yousef@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, linux-kernel@vger.kernel.org,
david.chen@nutanix.com, zhangqiao22@huawei.com
Subject: Re: [PATCH v2] sched/fair: fix case with reduced capacity CPU
Date: Mon, 11 Jul 2022 17:03:04 +0100 [thread overview]
Message-ID: <20220711160304.njkd3ml7nqpokiim@wubuntu> (raw)
In-Reply-To: <20220708154401.21411-1-vincent.guittot@linaro.org>
Hi Vincent
On 07/08/22 17:44, Vincent Guittot wrote:
> The capacity of the CPU available for CFS tasks can be reduced because of
> other activities running on the latter. In such case, it's worth trying to
> move CFS tasks on a CPU with more available capacity.
>
> The rework of the load balance has filtered the case when the CPU is
> classified to be fully busy but its capacity is reduced.
>
> Check if CPU's capacity is reduced while gathering load balance statistic
> and classify it group_misfit_task instead of group_fully_busy so we can
> try to move the load on another CPU.
>
> Reported-by: David Chen <david.chen@nutanix.com>
> Reported-by: Zhang Qiao <zhangqiao22@huawei.com>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> Tested-by: David Chen <david.chen@nutanix.com>
> Tested-by: Zhang Qiao <zhangqiao22@huawei.com>
> ---
[...]
> @@ -8820,8 +8833,9 @@ static inline void update_sg_lb_stats(struct lb_env *env,
>
> for_each_cpu_and(i, sched_group_span(group), env->cpus) {
> struct rq *rq = cpu_rq(i);
> + unsigned long load = cpu_load(rq);
>
> - sgs->group_load += cpu_load(rq);
> + sgs->group_load += load;
> sgs->group_util += cpu_util_cfs(i);
> sgs->group_runnable += cpu_runnable(rq);
> sgs->sum_h_nr_running += rq->cfs.h_nr_running;
> @@ -8851,11 +8865,17 @@ static inline void update_sg_lb_stats(struct lb_env *env,
> if (local_group)
> continue;
>
> - /* Check for a misfit task on the cpu */
> - if (env->sd->flags & SD_ASYM_CPUCAPACITY &&
> - sgs->group_misfit_task_load < rq->misfit_task_load) {
> - sgs->group_misfit_task_load = rq->misfit_task_load;
> - *sg_status |= SG_OVERLOAD;
> + if (env->sd->flags & SD_ASYM_CPUCAPACITY) {
> + /* Check for a misfit task on the cpu */
> + if (sgs->group_misfit_task_load < rq->misfit_task_load) {
> + sgs->group_misfit_task_load = rq->misfit_task_load;
> + *sg_status |= SG_OVERLOAD;
> + }
> + } else if ((env->idle != CPU_NOT_IDLE) &&
> + sched_reduced_capacity(rq, env->sd)) {
> + /* Check for a task running on a CPU with reduced capacity */
> + if (sgs->group_misfit_task_load < load)
> + sgs->group_misfit_task_load = load;
> }
> }
Small questions mostly for my education purposes.
The new condition only applies for SMP systems. The reason asym systems don't
care is because misfit check already considers capacity pressure when checking
that the task fits_capacity()?
It **seems** to me that the migration margin in fits_capacity() acts like the
sd->imbalance_pct when check_cpu_capacity() is called by
sched_reduced_capacity(), did I get it right?
If I got it right, if the migration margin ever tweaked, could we potentially
start seeing this kind of reported issue on asym systems then? I guess not. It
just seems to me for asym systems tweaking the migration margin is similar to
tweaking imbalance_pct for smp ones. But the subtlety is greater as
imbalance_pct is still used in asym systems.
Thanks
--
Qais Yousef
next prev parent reply other threads:[~2022-07-11 16:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 15:44 Vincent Guittot
2022-07-11 16:03 ` Qais Yousef [this message]
2022-07-11 16:42 ` Vincent Guittot
2022-07-12 10:52 ` Qais Yousef
2022-07-14 11:35 ` [tip: sched/core] " tip-bot2 for 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=20220711160304.njkd3ml7nqpokiim@wubuntu \
--to=qais.yousef@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=david.chen@nutanix.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=zhangqiao22@huawei.com \
/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®