All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Ruifeng Zhang <ruifeng.zhang0110@gmail.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: Mon, 19 Apr 2021 23:27:50 +0200	[thread overview]
Message-ID: <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com> (raw)
In-Reply-To: <CAG7+-3MX8Ntzh-fiTFZq-d9EO4GNpY2b3AuAOZPxVmxA=jNtNg@mail.gmail.com>

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.

[...]

> 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: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Ruifeng Zhang <ruifeng.zhang0110@gmail.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: Mon, 19 Apr 2021 23:27:50 +0200	[thread overview]
Message-ID: <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com> (raw)
In-Reply-To: <CAG7+-3MX8Ntzh-fiTFZq-d9EO4GNpY2b3AuAOZPxVmxA=jNtNg@mail.gmail.com>

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.

[...]

> 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-19 21:27 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 [this message]
2021-04-19 21:27                   ` Dietmar Eggemann
2021-04-23  6:25                   ` Ruifeng Zhang
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=31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=a.p.zijlstra@chello.nl \
    --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.zhang0110@gmail.com \
    --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.