From: Rohit Jain <rohit.k.jain@oracle.com>
To: Joel Fernandes <joelaf@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
eas-dev@lists.linaro.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Atish Patra <atish.patra@oracle.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>
Subject: Re: [PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling code path
Date: Tue, 26 Sep 2017 12:48:25 -0700 [thread overview]
Message-ID: <ffb62cdf-570c-227b-9390-06af864b6730@oracle.com> (raw)
In-Reply-To: <CAJWu+opTthUkQ=MFxy7mLgSzFZyM=1oh51s=pQDjyZaQa7Wngg@mail.gmail.com>
On 09/25/2017 11:53 PM, Joel Fernandes wrote:
> Hi Rohit,
>
> Just some comments:
Hi Joel,
Thanks for the comments.
> On Mon, Sep 25, 2017 at 5:02 PM, Rohit Jain <rohit.k.jain@oracle.com> wrote:
>> While looking for CPUs to place running tasks on, the scheduler
>> completely ignores the capacity stolen away by RT/IRQ tasks.
>>
>> This patch fixes that.
>>
>> Signed-off-by: Rohit Jain <rohit.k.jain@oracle.com>
>> ---
>> kernel/sched/fair.c | 54 ++++++++++++++++++++++++++++++++++++++++++-----------
>> 1 file changed, 43 insertions(+), 11 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index afb701f..19ff2c3 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -6040,7 +6040,10 @@ void __update_idle_core(struct rq *rq)
>> static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int target)
>> {
>> struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
>> - int core, cpu;
>> + int core, cpu, rcpu, rcpu_backup;
> I would call rcpu_backup as backup_cpu.
OK
>
>> + unsigned int backup_cap = 0;
>> +
>> + rcpu = rcpu_backup = -1;
>>
>> if (!static_branch_likely(&sched_smt_present))
>> return -1;
>> @@ -6057,10 +6060,20 @@ static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int
>> cpumask_clear_cpu(cpu, cpus);
>> if (!idle_cpu(cpu))
>> idle = false;
>> +
>> + if (full_capacity(cpu)) {
>> + rcpu = cpu;
>> + } else if ((rcpu == -1) && (capacity_of(cpu) > backup_cap)) {
>> + backup_cap = capacity_of(cpu);
>> + rcpu_backup = cpu;
>> + }
> Here you comparing capacity of different SMT threads.
>
>> }
>>
>> - if (idle)
>> - return core;
>> + if (idle) {
>> + if (rcpu == -1)
>> + return (rcpu_backup != -1 ? rcpu_backup : core);
>> + return rcpu;
>> + }
>
> This didn't make much sense to me, here you are returning either an
> SMT thread or a core. That doesn't make much of a difference because
> SMT threads share the same capacity (SD_SHARE_CPUCAPACITY). I think
> what you want to do is find out the capacity of a 'core', not an SMT
> thread, and compare the capacity of different cores and consider the
> one which has least RT/IRQ interference.
IIUC the capacities of each strand is scaled by IRQ and 'rt_avg' for that
'rq'. Now if the strand is idle now and gets an interrupt in the future,
the 'core' would look like:
+----+----+
| I | |
| T | |
+----+----+
(I -> Interrupt, T-> Thread we are trying to schedule).
whereas if the other strand on the core was taking interrupt the core
would look like:
+----+----+
| I | T |
| | |
+----+----+
With this case, because we know from the past avg, one of the strands is
running low on capacity, I am trying to return a better strand for the
thread to start on.
>
>> }
>>
>> /*
>> @@ -6076,7 +6089,8 @@ static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int
>> */
>> static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int target)
>> {
>> - int cpu;
>> + int cpu, backup_cpu = -1;
>> + unsigned int backup_cap = 0;
>>
>> if (!static_branch_likely(&sched_smt_present))
>> return -1;
>> @@ -6084,11 +6098,17 @@ static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int t
>> for_each_cpu(cpu, cpu_smt_mask(target)) {
>> if (!cpumask_test_cpu(cpu, &p->cpus_allowed))
>> continue;
>> - if (idle_cpu(cpu))
>> - return cpu;
>> + if (idle_cpu(cpu)) {
>> + if (full_capacity(cpu))
>> + return cpu;
>> + if (capacity_of(cpu) > backup_cap) {
>> + backup_cap = capacity_of(cpu);
>> + backup_cpu = cpu;
>> + }
>> + }
> Same thing here, since SMT threads share the same underlying capacity,
> is there any point in comparing the capacities of each SMT thread?
See above
Thanks,
Rohit
>
> thanks,
>
> - Joel
>
> [...]
next prev parent reply other threads:[~2017-09-26 19:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-26 0:02 [PATCH v4 0/3] sched/fair: Introduce scaled capacity awareness in enqueue Rohit Jain
2017-09-26 0:02 ` [PATCH 1/3] sched/fair: Introduce scaled capacity awareness in find_idlest_cpu code path Rohit Jain
2017-09-26 2:51 ` joelaf
2017-09-26 4:40 ` Rohit Jain
2017-09-26 6:59 ` Joel Fernandes
2017-09-26 0:02 ` [PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling " Rohit Jain
2017-09-26 6:53 ` Joel Fernandes
2017-09-26 19:48 ` Rohit Jain [this message]
2017-09-28 10:53 ` joelaf
2017-09-28 15:09 ` Rohit Jain
2017-10-03 4:52 ` Joel Fernandes
2017-10-04 0:21 ` Rohit Jain
2017-09-26 0:02 ` [PATCH 3/3] ignore_this_patch: Fixing compilation error on Peter's tree Rohit Jain
2017-10-01 0:32 ` kbuild test robot
-- strict thread matches above, loose matches on Subject: below --
2017-10-07 23:48 [PATCH v5 0/3] sched/fair: Introduce scaled capacity awareness in enqueue Rohit Jain
2017-10-07 23:48 ` [PATCH 2/3] sched/fair: Introduce scaled capacity awareness in select_idle_sibling code path Rohit Jain
2017-10-10 15:54 ` Atish Patra
2017-10-10 18:02 ` Rohit Jain
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=ffb62cdf-570c-227b-9390-06af864b6730@oracle.com \
--to=rohit.k.jain@oracle.com \
--cc=atish.patra@oracle.com \
--cc=dietmar.eggemann@arm.com \
--cc=eas-dev@lists.linaro.org \
--cc=joelaf@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.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