From: Pavan Kondeti <pkondeti@codeaurora.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, morten.rasmussen@arm.com,
qperret@google.com, adharmap@codeaurora.org
Subject: Re: [PATCH v3 1/3] sched/fair: Add asymmetric CPU capacity wakeup scan
Date: Wed, 29 Jan 2020 09:22:58 +0530 [thread overview]
Message-ID: <20200129035258.GB27398@codeaurora.org> (raw)
In-Reply-To: <1ed322d6-0325-ecac-cc68-326a14b8c1dd@arm.com>
On Tue, Jan 28, 2020 at 11:30:26AM +0000, Valentin Schneider wrote:
> Hi Pavan,
>
> On 28/01/2020 06:22, Pavan Kondeti wrote:
> > Hi Valentin,
> >
> > On Sun, Jan 26, 2020 at 08:09:32PM +0000, Valentin Schneider wrote:
> >>
> >> +static inline int check_cpu_capacity(struct rq *rq, struct sched_domain *sd);
> >> +
> >> +/*
> >> + * Scan the asym_capacity domain for idle CPUs; pick the first idle one on which
> >> + * the task fits. If no CPU is big enough, but there are idle ones, try to
> >> + * maximize capacity.
> >> + */
> >> +static int select_idle_capacity(struct task_struct *p, int target)
> >> +{
> >> + unsigned long best_cap = 0;
> >> + struct sched_domain *sd;
> >> + struct cpumask *cpus;
> >> + int best_cpu = -1;
> >> + struct rq *rq;
> >> + int cpu;
> >> +
> >> + if (!static_branch_unlikely(&sched_asym_cpucapacity))
> >> + return -1;
> >> +
> >> + sd = rcu_dereference(per_cpu(sd_asym_cpucapacity, target));
> >> + if (!sd)
> >> + return -1;
> >> +
> >> + sync_entity_load_avg(&p->se);
> >> +
> >> + cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
> >> + cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> >> +
> >> + for_each_cpu_wrap(cpu, cpus, target) {
> >> + rq = cpu_rq(cpu);
> >> +
> >> + if (!available_idle_cpu(cpu))
> >> + continue;
> >> + if (task_fits_capacity(p, rq->cpu_capacity))
> >> + return cpu;
> >
> > I have couple of questions.
> >
> > (1) Any particular reason for not checking sched_idle_cpu() as a backup
> > for the case where all eligible CPUs are busy? select_idle_cpu() does
> > that.
> >
>
> No particular reason other than we didn't consider it, I think. I don't see
> any harm in folding it in, I'll do that for v4. I am curious however; are
> you folks making use of SCHED_IDLE? AFAIA Android isn't making use of it
> yet, though Viresh paved the way for that to happen.
>
We are not using SCHED_IDLE in product setups. I am told Android may use it
for background tasks in future. I am not completely sure though. I asked it
because select_idle_cpu() is using it.
> > (2) Assuming all CPUs are busy, we return -1 from here and end up
> > calling select_idle_cpu(). The traversal in select_idle_cpu() may be
> > waste in cases where sd_llc == sd_asym_cpucapacity . For example SDM845.
> > Should we worry about this?
> >
>
> Before v3, since we didn't have the fallback CPU selection within
> select_idle_capacity(), we would need the fall-through to select_idle_cpu()
> (we could've skipped an idle CPU just because its capacity wasn't high
> enough).
>
> That's not the case anymore, so indeed we may be able to bail out of
> select_idle_sibling() right after select_idle_capacity() (or after the
> prev / recent_used_cpu checks). Our only requirement here is that sd_llc
> remains a subset of sd_asym_cpucapacity.
>
> So far for Arm topologies we can have:
> - sd_llc < sd_asym_cpucapacity (e.g. legacy big.LITTLE like Juno)
> - sd_llc == sd_asym_cpucapacity (e.g. DynamIQ like SDM845)
>
> I'm slightly worried about sd_llc > sd_asym_cpucapacity ever being an
> actual thing - I don't believe it makes much sense, but that's not stopping
> anyone.
>
> AFAIA we (Arm) *currently* don't allow that with big.LITTLE or DynamIQ, nor
> do I think it can happen with the default scheduler topology where MC is
> the last possible level we can have as sd_llc.
>
> So it *might* be a safe assumption - and I can still add a SCHED_WARN_ON().
Agreed.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2020-01-29 3:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 20:09 [PATCH v3 0/3] sched/fair: Capacity aware wakeup rework Valentin Schneider
2020-01-26 20:09 ` [PATCH v3 1/3] sched/fair: Add asymmetric CPU capacity wakeup scan Valentin Schneider
2020-01-28 6:22 ` Pavan Kondeti
2020-01-28 11:30 ` Valentin Schneider
2020-01-29 3:52 ` Pavan Kondeti [this message]
2020-01-29 8:16 ` Qais Yousef
2020-01-29 9:25 ` Valentin Schneider
2020-01-29 10:38 ` Dietmar Eggemann
2020-01-29 12:10 ` Valentin Schneider
2020-01-29 11:04 ` Dietmar Eggemann
2020-01-29 12:10 ` Valentin Schneider
2020-01-26 20:09 ` [PATCH v3 2/3] sched/topology: Remove SD_BALANCE_WAKE on asymmetric capacity systems Valentin Schneider
2020-01-29 16:27 ` Dietmar Eggemann
2020-01-30 11:06 ` Valentin Schneider
2020-01-26 20:09 ` [PATCH v3 3/3] sched/fair: Kill wake_cap() Valentin Schneider
2020-01-28 9:24 ` [PATCH v3 0/3] sched/fair: Capacity aware wakeup rework Dietmar Eggemann
2020-01-28 11:34 ` Valentin Schneider
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=20200129035258.GB27398@codeaurora.org \
--to=pkondeti@codeaurora.org \
--cc=adharmap@codeaurora.org \
--cc=dietmar.eggemann@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=valentin.schneider@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.