From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Yicong Yang <yangyicong@huawei.com>,
sudeep.holla@arm.com, pierre.gondois@arm.com
Cc: dave.hansen@linux.intel.com, bp@alien8.de, mingo@redhat.com,
linux-arm-kernel@lists.infradead.org, mpe@ellerman.id.au,
peterz@infradead.org, tglx@linutronix.de, will@kernel.org,
catalin.marinas@arm.com, yangyicong@hisilicon.com,
linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
linux-kernel@vger.kernel.org, morten.rasmussen@arm.com,
msuchanek@suse.de, gregkh@linuxfoundation.org, rafael@kernel.org,
jonathan.cameron@huawei.com, prime.zeng@hisilicon.com,
linuxarm@huawei.com, xuwei5@huawei.com, guohanjun@huawei.com,
sshegde@linux.ibm.com
Subject: Re: [PATCH v11 2/4] arch_topology: Support SMT control for OF based system
Date: Tue, 4 Mar 2025 10:32:13 +0100 [thread overview]
Message-ID: <5435fd87-6209-4896-84cc-27a35ef3cea4@arm.com> (raw)
In-Reply-To: <21e74021-fb68-0003-f0f4-7f54dd674b9d@huawei.com>
On 03/03/2025 15:03, Yicong Yang wrote:
> On 2025/2/28 19:11, Dietmar Eggemann wrote:
>> On 18/02/2025 15:10, Yicong Yang wrote:
>>> From: Yicong Yang <yangyicong@hisilicon.com>
[...]
>>> If a system have more than one SMT thread number the 2) may
>>
>> s/have/has
>>
>>> not handle it well, since there're multiple thread numbers in the
>>
>> multiple thread numbers other than 1, right?
>
> according to the pr_warn_once() we implemented below it also includes the case
> where the system have one type of SMT cores and non-SMT cores (the thread number is 1):
> - 1 thread
> - X (!= 1) threads
>
> Discussion made in [1] and I thought we have agreement (hope I understood correctly)
> that all the asymmetric cases need to notify. Do you and Sudeep think we should not
> warn in such case?
Systems with non-SMT and SMT-2 cores are IMHO a special case since for
them the '/sys/devices/system/cpu/smt' interface still works correctly.
And on X86 those systems do exist today.
IMHO, it would be awkward to see the message 'Heterogeneous SMT topology
is partly supported by SMT control' on arm64 but not on x86 on such a
system.
I do understand that this message is more tailored to theoretically
possible 'multiple SMT-X (X>1) core' systems (e.g. 1,2,4).
And here we cannot issue a '2 > ./control' since
cpu_smt_num_threads_valid() only returns true for 1 or 4.
IMHO, I would remove the warning and state clearly in the patch that for
systems with multiple SMT-X (X>1) cores, this interface only support SMT
completely on or off.
Example Arm64 DT:
cpu-map {
cluster0 {
core0 {
thread0 {
cpu = <&A53_0>;
};
};
core1 {
thread0 {
cpu = <&A53_1>;
};
};
core2 {
thread0 {
cpu = <&A53_2>;
};
thread1 {
cpu = <&A53_3>;
};
};
core3 {
thread0 {
cpu = <&A53_4>;
};
thread1 {
cpu = <&A53_5>;
};
thread2 {
cpu = <&A53_6>;
};
thread3 {
cpu = <&A53_7>;
};
};
};
};
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
/sys/devices/system/cpu/smt# echo 1 >control
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 4
/sys/devices/system/cpu/smt# echo 2 >control
-bash: echo: write error: Invalid argument
[...]
next prev parent reply other threads:[~2025-03-04 9:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 14:10 [PATCH v11 0/4] Support SMT control on arm64 Yicong Yang
2025-02-18 14:10 ` [PATCH v11 1/4] cpu/SMT: Provide a default topology_is_primary_thread() Yicong Yang
2025-02-28 11:10 ` Dietmar Eggemann
2025-03-03 13:35 ` Yicong Yang
2025-02-28 13:54 ` Sudeep Holla
2025-03-03 13:38 ` Yicong Yang
2025-02-18 14:10 ` [PATCH v11 2/4] arch_topology: Support SMT control for OF based system Yicong Yang
2025-02-28 11:11 ` Dietmar Eggemann
2025-03-03 14:03 ` Yicong Yang
2025-03-04 9:32 ` Dietmar Eggemann [this message]
2025-02-28 13:54 ` Sudeep Holla
2025-03-03 14:11 ` Yicong Yang
2025-02-18 14:10 ` [PATCH v11 3/4] arm64: topology: Support SMT control on ACPI " Yicong Yang
2025-02-25 6:08 ` Hanjun Guo
2025-03-03 14:42 ` Yicong Yang
2025-02-28 11:11 ` Dietmar Eggemann
2025-02-28 13:56 ` Sudeep Holla
2025-02-28 17:51 ` Pierre Gondois
2025-02-28 19:06 ` Sudeep Holla
2025-03-03 9:56 ` Pierre Gondois
2025-03-03 11:16 ` Sudeep Holla
2025-03-03 14:40 ` Yicong Yang
2025-03-04 8:25 ` Pierre Gondois
2025-03-04 10:02 ` Sudeep Holla
2025-03-04 15:07 ` Pierre Gondois
2025-03-05 9:01 ` Yicong Yang
2025-02-18 14:10 ` [PATCH v11 4/4] arm64: Kconfig: Enable HOTPLUG_SMT Yicong Yang
2025-02-28 11:12 ` [PATCH v11 0/4] Support SMT control on arm64 Dietmar Eggemann
2025-03-03 14:41 ` Yicong Yang
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=5435fd87-6209-4896-84cc-27a35ef3cea4@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=mpe@ellerman.id.au \
--cc=msuchanek@suse.de \
--cc=peterz@infradead.org \
--cc=pierre.gondois@arm.com \
--cc=prime.zeng@hisilicon.com \
--cc=rafael@kernel.org \
--cc=sshegde@linux.ibm.com \
--cc=sudeep.holla@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xuwei5@huawei.com \
--cc=yangyicong@hisilicon.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;
as well as URLs for NNTP newsgroup(s).