mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: "tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"bp@alien8.de" <bp@alien8.de>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"bsegall@google.com" <bsegall@google.com>,
	"mgorman@suse.de" <mgorman@suse.de>,
	"msys.mizuma@gmail.com" <msys.mizuma@gmail.com>,
	"valentin.schneider@arm.com" <valentin.schneider@arm.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"sudeep.holla@arm.com" <sudeep.holla@arm.com>,
	"aubrey.li@linux.intel.com" <aubrey.li@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"xuwei (O)" <xuwei5@huawei.com>,
	"Zengtao (B)" <prime.zeng@hisilicon.com>,
	"guodong.xu@linaro.org" <guodong.xu@linaro.org>,
	yangyicong <yangyicong@huawei.com>,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"peterz@infradead.org" <peterz@infradead.org>
Subject: RE:  Re: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks within one LLC
Date: Thu, 29 Apr 2021 02:38:08 +0000	[thread overview]
Message-ID: <a54d76d3c59149aba74ddd464b2c64a9@hisilicon.com> (raw)

> >>
> >>> -----Original Message-----
> >>> From: Dietmar Eggemann [mailto:dietmar.eggemann@arm.com]
> 
> [...]
> 
> >>> On 20/04/2021 02:18, Barry Song wrote:
> 
> [...]
> 
> >> I am really confused. The whole code has only checked if wake_flags
> >> has WF_TTWU, it has never checked if sd_domain has SD_BALANCE_WAKE flag.
> >
> > look at :
> > #define WF_TTWU     0x08 /* Wakeup;            maps to SD_BALANCE_WAKE */
> >
> > so  when wake_wide return false, we use the wake_affine mecanism but
> > if it's false then we fllback to default mode which looks for:
> > if (tmp->flags & sd_flag)
> >
> > This means looking for SD_BALANCE_WAKE which is never set
> >
> > so sd will stay NULL and you will end up calling select_idle_sibling anyway
> >
> >>
> >> static int
> >> select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
> >> {
> >>         ...
> >>
> >>         if (wake_flags & WF_TTWU) {
> >>                 record_wakee(p);
> >>
> >>                 if (sched_energy_enabled()) {
> >>                         new_cpu = find_energy_efficient_cpu(p, prev_cpu);
> >>                         if (new_cpu >= 0)
> >>                                 return new_cpu;
> >>                         new_cpu = prev_cpu;
> >>                 }
> >>
> >>                 want_affine = !wake_wide(p) && cpumask_test_cpu(cpu,
> p->cpus_ptr);
> >>         }
> >> }
> >>
> >> And try_to_wake_up() has always set WF_TTWU:
> >> static int
> >> try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> >> {
> >>         cpu = select_task_rq(p, p->wake_cpu, wake_flags | WF_TTWU);
> >>         ...
> >> }
> >>
> >> So the change in wake_wide will actually affect the value of want_affine.
> >> And I did also see code entered slow path during my benchmark.
> 
> Yes, this is happening but IMHO not for wakeups. Check wake_flags for
> the tasks which go through `slow path` on your machine. They should have
> WF_EXEC or WF_FORK, not WF_TTWU (& WF_SYNC).

Yes. Both of you are right. The slow path I reported yesterday came from
WF_FORK actually.

> 
> >> One issue I mentioned during linaro open discussion is that
> >> since I have moved to use cluster size to decide the value
> >> of wake_wide, relatively less tasks will make wake_wide()
> >> decide to go to slow path, thus, tasks begin to spread to
> >> other NUMA,  but actually llc_size might be able to contain
> >> those tasks. So a possible model might be:
> >> static int wake_wide(struct task_struct *p)
> >> {
> >>         tasksize < cluster : scan cluster
> >>         tasksize > llc      : slow path
> >>         tasksize > cluster && tasksize < llc: scan llc
> >> }
> >>
> >> thoughts?
> 
> Like Vincent explained, the return value of wake_wide() doesn't matter.
> For wakeups you always end up in sis().

Though we will never go to slow path, wake_wide() will affect want_affine,
so eventually affect the "new_cpu"?

	for_each_domain(cpu, tmp) {
		/*
		 * If both 'cpu' and 'prev_cpu' are part of this domain,
		 * cpu is a valid SD_WAKE_AFFINE target.
		 */
		if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
		    cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
			if (cpu != prev_cpu)
				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);

			sd = NULL; /* Prefer wake_affine over balance flags */
			break;
		}

		if (tmp->flags & sd_flag)
			sd = tmp;
		else if (!want_affine)
			break;
	}

If wake_affine is false, the above won't execute, new_cpu(target) will
always be "prev_cpu"? so when "task size > cluster size" in wake_wide(),
this means we won't pull the wakee to the cluster of waker since target
is always prev_cpu? It seems sensible.

Thanks
Barry


                 reply	other threads:[~2021-04-29  2:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=a54d76d3c59149aba74ddd464b2c64a9@hisilicon.com \
    --to=song.bao.hua@hisilicon.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guodong.xu@linaro.org \
    --cc=hpa@zytor.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=juri.lelli@redhat.com \
    --cc=lenb@kernel.org \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=msys.mizuma@gmail.com \
    --cc=peterz@infradead.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xuwei5@huawei.com \
    --cc=yangyicong@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®