[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o6rowrsp.ffs@tglx>
Date: Fri, 05 Sep 2025 22:47:02 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux PM
<linux-pm@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>,
Christian Loehle <christian.loehle@....com>, Dave Hansen
<dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v1] cpu: Add missing check to cpuhp_smt_enable()
On Fri, Sep 05 2025 at 15:27, Rafael J. Wysocki wrote:
> On Fri, Sep 5, 2025 at 3:13 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>> Well, manual online can be used for onlining the secondary thread of a
>> core where the primary thread is offline, so this is technically
>> possible already.
>>
>> > Something like the completely untested below.
>>
>> So given the above, shouldn't topology_is_core_online() check if any
>> thread in the given core is online?
>
> Besides, this would cause the siblings of offline SMT threads to be
> skipped while enabling SMT via sysfs (using
> /sys/devices/system/cpu/smt/control), but I'm not sure if this is the
> expectation in the field today. The current behavior is to online all
> secondary SMT threads (and more, but that part is quite arguably
> broken).
It is broken, because the initial logic is to bring up primary threads
unconditionally and then refuse to bring up sibling threads.
With "maxcpus=xxx" this obviously limits the amount of primary threads,
so there is arguably no point to online any of the related secondary
threads of them.
The initial implementation was naively making that assumption, but the
core check which was added due to PPC made this actually correct.
It just did not snap with me back then, but it's actually the correct
thing to do, no?
Thanks,
tglx
Powered by blists - more mailing lists