All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Zhou <tao.zhou@linux.dev>
To: Barry Song <21cnbao@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH] sched/fair: Check idle_cpu in select_idle_core/cpu()
Date: Sun, 10 Oct 2021 22:27:24 +0800	[thread overview]
Message-ID: <YWL4TA19eFsfd4c7@geo.homenetwork> (raw)
In-Reply-To: <CAGsJ_4xW5s-ze6QjVLJPscEcCaakdS6Np84w9Hwh8Zj_=WqhTw@mail.gmail.com>

Hi Barry,

On Mon, Oct 11, 2021 at 01:19:57AM +1300, Barry Song wrote:
> On Sun, Oct 10, 2021 at 10:45 PM Tao Zhou <tao.zhou@linux.dev> wrote:
> >
> > Hi Peter,
> >
> > On Sun, Oct 10, 2021 at 12:50:57AM +0200, Peter Zijlstra wrote:
> > > On Sun, Oct 10, 2021 at 02:09:41AM +0800, Tao Zhou wrote:
> > > > In select_idle_core(), the idle core returned may have no cpu
> > > > allowed. I think the idle core returned for the task is the one
> > > > that can be allowed to run. I insist on this semantics.
> > > >
> > > > In select_idle_cpu(), if select_idle_core() can not find the
> > > > idle core, one reason is that the core is not allowed for the
> > > > task, but the core itself is idle from the point of
> > > > sds->has_idle_cores. I insist on this semantics.
> > > >
> > > > No others, just two additional check.
> > > > ---
> > > >  kernel/sched/fair.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > index f6a05d9b5443..a44aca5095d3 100644
> > > > --- a/kernel/sched/fair.c
> > > > +++ b/kernel/sched/fair.c
> > > > @@ -6213,7 +6213,7 @@ static int select_idle_core(struct task_struct *p, int core, struct cpumask *cpu
> > > >                     *idle_cpu = cpu;
> > > >     }
> > > >
> > > > -   if (idle)
> > > > +   if (idle && *idle_cpu != -1)
> > > >             return core;
> > >
> > > In that case, core would be nr_cpu_ids (==nr_cpumask_bits), and then the caller checks:
> > >
> > >       (unsigned)i < nr_cpumask_bits
> >
> > Thank you for reply.
> >
> >
> > If (1)there is no idle core or (2)the idle core has no allowed cpu, we return -1.
> > Originally, just (1) has happened, we return -1. The (2) is what I want to add.
> 
> I don't understand (2). before doing
>         for_each_cpu_wrap(cpu, cpus, target + 1) {
>                 if (has_idle_core) {
>                         i = select_idle_core(p, cpu, cpus, &idle_cpu);
>                         if ((unsigned int)i < nr_cpumask_bits)
>                                 return i;
> 
>                 } else {
>                         if (!--nr)
>                                 return -1;
>                         idle_cpu = __select_idle_cpu(cpu, p);
>                         if ((unsigned int)idle_cpu < nr_cpumask_bits)
>                                 break;
>                 }
>         }
> 
> to select idle core, we have already done:
>     cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
> 
> so we are only scanning allowed cpus.

Um.. You read top down.. and you are right.
The function itself semantics is important to me.

After a secondary recall and not thorough now, I realize that
cpus_ptr may be changed.


See code of this:

static void migrate_disable_switch(struct rq *rq, struct task_struct *p)
{
	if (likely(!p->migration_disabled))
		return;

	if (p->cpus_ptr != &p->cpus_mask)
		return;

	/*
	 * Violates locking rules! see comment in __do_set_cpus_allowed().
	 */
	__do_set_cpus_allowed(p, cpumask_of(rq->cpu), SCA_MIGRATE_DISABLE);
}


This change is under the light of ->pi_lock.
That thing is quick to forget to me..
Not sure I am right. Thank you for remind.

If the cpu_ptr can be changed, you can not depend on the first AND
operation there.

> >
> > If we find idle core and has allowed cpu in the core, is it better to return
> > @*idle_cpu.
> >
> >     if (idle && *idle_cpu != -1)
> >             return *idle_cpu;
> >
> > This @*idle_cpu is the allowed cpu in the idle core. We do not promise anything
> > about the @core(target) is the allowed cpu until we hit in select_task_rq() -->
> > select_fallback_rq(). And the select_fallback_rq() will return a different cpu
> > than the @core or @*idle_cpu.
> >
> > > >     cpumask_andnot(cpus, cpus, cpu_smt_mask(core));
> > > > @@ -6324,7 +6324,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool
> > > >             }
> > > >     }
> > > >
> > > > -   if (has_idle_core)
> > > > +   if (has_idle_core && *idle_cpu != -1)
> > > >             set_idle_cores(target, false);
> > >
> > > And this one I'm completely failing, why shouldn't we mark the core as
> > > non-idle when there is a single idle CPU found? That's just worng.
> >
> > When @has_idle_core is true, it implies for all cpu in the core the case
> > (1) or case (2) has happened. The (1) can be mark as non-idle. I conclude
> > to contradiction myself last time. The (2) is also seemed to be non-idle.
> >
> >
> > But, I think I am totally wrong because the sds->has_idle_cores is related
> > to the cpu not task. So, the affinity should not affect the decision of
> > sds->has_idle_cores.
> >
> >
> >
> > Thanks,
> > Tao
> 
> Thanks
> barry



Thanks,
Tao

  reply	other threads:[~2021-10-10 14:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-09 18:09 [PATCH] sched/fair: Check idle_cpu in select_idle_core/cpu() Tao Zhou
2021-10-09 22:50 ` Peter Zijlstra
2021-10-10  9:39   ` Tao Zhou
2021-10-10 12:19     ` Barry Song
2021-10-10 14:27       ` Tao Zhou [this message]
2021-10-10 20:24         ` Barry Song

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=YWL4TA19eFsfd4c7@geo.homenetwork \
    --to=tao.zhou@linux.dev \
    --cc=21cnbao@gmail.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.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 \
    /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.