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
next prev parent 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: linkBe 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.