All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ruifeng Zhang <ruifeng.zhang0110@gmail.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>,
	linux@armlinux.org.uk, sudeep.holla@arm.com,
	Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	a.p.zijlstra@chello.nl, mingo@kernel.org,
	ruifeng.zhang1@unisoc.com, nianfu.bai@unisoc.com,
	linux-arm-kernel@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/1] arm: topology: parse the topology from the dt
Date: Fri, 23 Apr 2021 14:25:25 +0800	[thread overview]
Message-ID: <CAG7+-3OMkC_tYEKeXW6MGrsTbEsf6iUG24-9TYJGL-Kh6Dr83A@mail.gmail.com> (raw)
In-Reply-To: <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com>

Dietmar Eggemann <dietmar.eggemann@arm.com> 于2021年4月20日周二 上午5:27写道:
>
> On 19/04/2021 04:55, Ruifeng Zhang wrote:
> > Dietmar Eggemann <dietmar.eggemann@arm.com> 于2021年4月17日周六 上午1:00写道:
> >>
> >> On 16/04/2021 13:04, Ruifeng Zhang wrote:
> >>> Dietmar Eggemann <dietmar.eggemann@arm.com> 于2021年4月16日周五 下午6:39写道:
> >>>>
> >>>> On 16/04/2021 11:32, Valentin Schneider wrote:
> >>>>> On 16/04/21 15:47, Ruifeng Zhang wrote:
>
> [...]
>
> >> I'm afraid that this is now a much weaker case to get this into
> >> mainline.
> >
> > But it's still a problem and it's not break the original logic ( parse
> > topology from MPIDR or parse capacity ), only add the support for
> > parse topology from DT.
> > I think it should still be merged into the mainline. If don't, the
> > DynamIQ SoC has some issue in sched and cpufreq.
>
> IMHO, not necessarily. Your DynamIQ SoC is one cluster with 8 CPUs. It's
> subdivided into 2 Frequency Domains (FDs).
>
> CFS Energy-Aware-Scheduling (EAS, find_energy_efficient_cpu()) and
> Capacity-Aware-Scheduling (CAS, select_idle_sibling() ->
> select_idle_capacity()) work correctly even in case you only have an MC
> sched domain (sd).
> No matter which sd (MC, DIE) the sd_asym_cpucapacity is, we always
> iterate over all CPUs. Per Performance Domains (i.e. FDs) in EAS and
> over sched_domain_span(sd) in CAS.
>
> CFS load-balancing (in case your system is `over-utilized`) might work
> slightly different due to the missing DIE sd but not inevitably worse.
>
> Do you have benchmarks or testcases in mind which convince you that
> Phantom Domains is something you would need? BTW, they are called
> Phantom since they let you use uarch and/or max CPU frequency domain to
> fake real topology (like LLC) boundaries.

I'm researching the impact of all CPUs in the same cluster, such as
DVFS. If there is any progress in the future, I hope to keep
communicating with you. Thank you very much.
>
> [...]
>
> > Why do you keep the logic of topology_parse_cpu_capacity in arm
> > get_coretype_capacity function? The capacity-dmips-mhz will be parsed
> > by drivers/base/arch_topology.c as following:
> > parse_dt_topology
> >     parse_cluster
> >         parse_core
> >             get_cpu_for_node
> >                 topology_parse_cpu_capacity
>
> I think we still need it for systems out there w/o cpu-map in dt, like
> my arm32 TC2 with mainline vexpress-v2p-ca15_a7.dts.
>
> It's called twice on each CPU in case I add the cpu-map dt entry though.

WARNING: multiple messages have this Message-ID (diff)
From: Ruifeng Zhang <ruifeng.zhang0110@gmail.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>,
	linux@armlinux.org.uk, sudeep.holla@arm.com,
	 Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	a.p.zijlstra@chello.nl,  mingo@kernel.org,
	ruifeng.zhang1@unisoc.com, nianfu.bai@unisoc.com,
	 linux-arm-kernel@lists.infradead.org,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/1] arm: topology: parse the topology from the dt
Date: Fri, 23 Apr 2021 14:25:25 +0800	[thread overview]
Message-ID: <CAG7+-3OMkC_tYEKeXW6MGrsTbEsf6iUG24-9TYJGL-Kh6Dr83A@mail.gmail.com> (raw)
In-Reply-To: <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com>

Dietmar Eggemann <dietmar.eggemann@arm.com> 于2021年4月20日周二 上午5:27写道:
>
> On 19/04/2021 04:55, Ruifeng Zhang wrote:
> > Dietmar Eggemann <dietmar.eggemann@arm.com> 于2021年4月17日周六 上午1:00写道:
> >>
> >> On 16/04/2021 13:04, Ruifeng Zhang wrote:
> >>> Dietmar Eggemann <dietmar.eggemann@arm.com> 于2021年4月16日周五 下午6:39写道:
> >>>>
> >>>> On 16/04/2021 11:32, Valentin Schneider wrote:
> >>>>> On 16/04/21 15:47, Ruifeng Zhang wrote:
>
> [...]
>
> >> I'm afraid that this is now a much weaker case to get this into
> >> mainline.
> >
> > But it's still a problem and it's not break the original logic ( parse
> > topology from MPIDR or parse capacity ), only add the support for
> > parse topology from DT.
> > I think it should still be merged into the mainline. If don't, the
> > DynamIQ SoC has some issue in sched and cpufreq.
>
> IMHO, not necessarily. Your DynamIQ SoC is one cluster with 8 CPUs. It's
> subdivided into 2 Frequency Domains (FDs).
>
> CFS Energy-Aware-Scheduling (EAS, find_energy_efficient_cpu()) and
> Capacity-Aware-Scheduling (CAS, select_idle_sibling() ->
> select_idle_capacity()) work correctly even in case you only have an MC
> sched domain (sd).
> No matter which sd (MC, DIE) the sd_asym_cpucapacity is, we always
> iterate over all CPUs. Per Performance Domains (i.e. FDs) in EAS and
> over sched_domain_span(sd) in CAS.
>
> CFS load-balancing (in case your system is `over-utilized`) might work
> slightly different due to the missing DIE sd but not inevitably worse.
>
> Do you have benchmarks or testcases in mind which convince you that
> Phantom Domains is something you would need? BTW, they are called
> Phantom since they let you use uarch and/or max CPU frequency domain to
> fake real topology (like LLC) boundaries.

I'm researching the impact of all CPUs in the same cluster, such as
DVFS. If there is any progress in the future, I hope to keep
communicating with you. Thank you very much.
>
> [...]
>
> > Why do you keep the logic of topology_parse_cpu_capacity in arm
> > get_coretype_capacity function? The capacity-dmips-mhz will be parsed
> > by drivers/base/arch_topology.c as following:
> > parse_dt_topology
> >     parse_cluster
> >         parse_core
> >             get_cpu_for_node
> >                 topology_parse_cpu_capacity
>
> I think we still need it for systems out there w/o cpu-map in dt, like
> my arm32 TC2 with mainline vexpress-v2p-ca15_a7.dts.
>
> It's called twice on each CPU in case I add the cpu-map dt entry though.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-23  6:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 12:23 [PATCH v2 0/1] arm: topology: parse the topology from the dt Ruifeng Zhang
2021-04-14 12:23 ` Ruifeng Zhang
2021-04-14 12:23 ` [PATCH v2 1/1] " Ruifeng Zhang
2021-04-14 12:23   ` Ruifeng Zhang
2021-04-14 12:38   ` Ruifeng Zhang
2021-04-14 12:38     ` Ruifeng Zhang
2021-04-15 18:09   ` Valentin Schneider
2021-04-15 18:09     ` Valentin Schneider
2021-04-15 18:09 ` [PATCH v2 0/1] " Valentin Schneider
2021-04-15 18:09   ` Valentin Schneider
2021-04-15 20:10   ` Dietmar Eggemann
2021-04-15 20:10     ` Dietmar Eggemann
2021-04-16  7:47     ` Ruifeng Zhang
2021-04-16  7:47       ` Ruifeng Zhang
2021-04-16  9:32       ` Valentin Schneider
2021-04-16  9:32         ` Valentin Schneider
2021-04-16 10:39         ` Dietmar Eggemann
2021-04-16 10:39           ` Dietmar Eggemann
2021-04-16 10:47           ` Valentin Schneider
2021-04-16 10:47             ` Valentin Schneider
2021-04-16 11:04           ` Ruifeng Zhang
2021-04-16 11:04             ` Ruifeng Zhang
2021-04-16 17:00             ` Dietmar Eggemann
2021-04-16 17:00               ` Dietmar Eggemann
2021-04-19  2:55               ` Ruifeng Zhang
2021-04-19  2:55                 ` Ruifeng Zhang
2021-04-19 21:27                 ` Dietmar Eggemann
2021-04-19 21:27                   ` Dietmar Eggemann
2021-04-23  6:25                   ` Ruifeng Zhang [this message]
2021-04-23  6:25                     ` Ruifeng Zhang

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=CAG7+-3OMkC_tYEKeXW6MGrsTbEsf6iUG24-9TYJGL-Kh6Dr83A@mail.gmail.com \
    --to=ruifeng.zhang0110@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mingo@kernel.org \
    --cc=nianfu.bai@unisoc.com \
    --cc=rafael@kernel.org \
    --cc=ruifeng.zhang1@unisoc.com \
    --cc=sudeep.holla@arm.com \
    --cc=valentin.schneider@arm.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 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.