* Re: [PATCH] thermal: core: fix use-after-free due to init/cancel delayed_work race
From: Mauricio Faria de Oliveira @ 2026-03-26 17:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm, linux-kernel,
kernel-dev, syzbot+3b3852c6031d0f30dfaf
In-Reply-To: <CAJZ5v0goUgYXwyR-G_5zu+wTfbCH5B4B0JL1pU9+cdHbKqT-Lw@mail.gmail.com>
On 2026-03-25 17:20, Rafael J. Wysocki wrote:
> On Wed, Mar 25, 2026 at 4:13 PM Mauricio Faria de Oliveira
> <mfo@igalia.com> wrote:
>>
>> On 2026-03-25 11:28, Mauricio Faria de Oliveira wrote:
>> > On 2026-03-25 11:17, Mauricio Faria de Oliveira wrote:
>> >> Thanks for looking into this.
>> >>
>> >> On 2026-03-25 09:47, Rafael J. Wysocki wrote:
>> >>> I can see the one between thermal_zone_device_unregister() and
>> >>> thermal_zone_device_resume(), but that can be addressed by adding a
>> >>> TZ_STATE_FLAG_EXIT check to the latter AFAICS.
>> >>
>> >
>> > Please disregard this paragraph; I incorrectly read/wrote _resume()
>> > as thermal_zone_pm_complete() discussed above. The rest should be
>> > right. I'll review this and get back shortly.
>> >
>> >> In the example describe above and detailed below, apparently that
>> >> is not sufficient, if I'm not missing anything. See, if _resume()
>> >> is reached with thermal_list_lock held, thermal_zone_device_exit()
>> >> is waiting for thermal_list_lock before setting TZ_STATE_FLAG_EXIT,
>> >> thus a check for it in _resume() would find it clear yet.
>>
>> Ok, similarly:
>>
>> Say, thermal_pm_notify() -> thermal_pm_notify_complete() ->
>> thermal_zone_pm_complete()
>> run before thermal_zone_device_unregister() is called;
>> thermal_zone_device_resume()
>> starts, and by now thermal_zone_device_unregister() is called.
>>
>> If thermal_zone_device_resume() wins the race over thermal_zone_exit()
>> for guard(thermal_zone(tz) (tz->lock), it sees TZ_STATE_FLAG_EXIT clear;
>> note its callees (eg, thermal_zone_device_init()) run with tz->lock
>> held,
>> so they see it clear as well.
>>
>> So, thermal_zone_device_init() calls INIT_DELAYED_WORK(), everything
>> returns, tz->lock is released and the thermal_zone_device_unregister()
>> -> thermal_zone_exit() path can continue to run.
>>
>> Only now thermal_zone_exit() sets TZ_STATE_FLAG_EXIT (too late),
>> returns.
>> cancel_delayed_work_sync() does not wait for
>> thermal_zone_device_resume()
>> due to INIT_DELAYED_WORK() in thermal_zone_device_init(); and kfree(tz).
>
> Wait.
>
> I'm not sure why this matters because the zone lock is dropped at the
> end of thermal_zone_device_resume() at which point it has done
> everything it had to do. Then, the cancel_delayed_work_sync() in
> thermal_zone_device_unregister() should properly wait for the work
> item queued up by thermal_zone_device_resume().
Oh, indeed, you're right.
>> Then, thermal_zone_device_resume() accesses tz and hits use-after-free.
>
> Say thermal_zone_device_resume() has lost the race for tz->lock to
> thermal_zone_exit() though. It runs after the latter and
> reinitializes the delayed work. Now, thermal_zone_device_unregister()
> continues and cancel_delayed_work_sync() doesn't see the
> thermal_zone_device_resume() running in parallel with it any more, so
> it doesn't wait and if thermal_zone_device_unregister() continues to
> run, it may free tz prematurely.
>
> I claim that this can be prevented by adding a tz->state check to
> thermal_zone_device_resume() before the reinitialization of the
> delayed work. Namely, if it loses the race tz->lock to
> thermal_zone_exit(), the new check will trigger and the delayed work
> will not be reinitialized, so the cancel_delayed_work_sync() will wait
> for it to complete.
I see it in this case now, thanks for clarifying.
--
Mauricio
^ permalink raw reply
* Re: [PATCH] thermal: core: fix use-after-free due to init/cancel delayed_work race
From: Mauricio Faria de Oliveira @ 2026-03-26 17:41 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm, linux-kernel,
kernel-dev, syzbot+3b3852c6031d0f30dfaf
In-Reply-To: <CAJZ5v0irL14vtz35zKF9ZPH8M1TN6i5mWkT2zQyB5d+LBPUXHg@mail.gmail.com>
On 2026-03-25 16:29, Rafael J. Wysocki wrote:
> On Wed, Mar 25, 2026 at 8:22 PM Mauricio Faria de Oliveira
> <mfo@igalia.com> wrote:
>>
>> On 2026-03-25 13:24, Rafael J. Wysocki wrote:
[...]
>> > I'd say that thermal_zone_device_unregister() needs to flush the
>> > workqueue before calling cancel_delayed_work_sync() to get rid of the
>> > stuff that may be running out of it that hasn't seen the changes made
>> > by thermal_zone_exit().
>>
>> IIUIC, cancel_delayed_work_sync() has that effect: it waits for
>> (specific)
>> work that might be running and hasn't seen changes by
>> thermal_zone_exit()).
>
> Sure, but you argued yourself that this didn't work if the work item
> in question had been reinitialized in the meantime.
Yes, if. To clarify: the above refers to cancel_delayed_work_sync()
behavior alone, not assuming a work item reinitialization (i.e., in
the context of the proposed patch).
> And I don't want to add another work item to the thermal zone
> structure just for the handling of suspend/resume.
That's certainly understandable.
--
Mauricio
^ permalink raw reply
* Re: [PATCH v2] thermal/drivers/mediatek/lvts: add missing fields for mt7987
From: Frank Wunderlich @ 2026-03-26 17:07 UTC (permalink / raw)
To: Frank Wunderlich, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-pm, linux-kernel, Daniel Golle, Laura Nao, linux-mediatek,
linux-arm-kernel
In-Reply-To: <20260312202433.39092-1-linux@fw-web.de>
Hi,
just a friedly reminder
@angelo do my mails get tagged as spam or similar?
Am 12. März 2026 um 21:24 schrieb "Frank Wunderlich" <linux@fw-web.de mailto:linux@fw-web.de?to=%22Frank%20Wunderlich%22%20%3Clinux%40fw-web.de%3E >:
>
> From: Frank Wunderlich <frank-w@public-files.de>
>
> Commit a4c40559499f ("thermal/drivers/mediatek/lvts: Add platform ops to
> support alternative conversion logic") added new ops field which causes
> crash on mt7987.
>
> [ 1.518540] Internal error: Oops: 0000000096000005 [#1] SMP
> ...
> [ 1.564481] pc : lvts_get_temp+0x84/0xc4
> [ 1.564492] lr : lvts_get_temp+0x60/0xc4
> ...
> [ 1.620900] Call trace:
> [ 1.631753] lvts_get_temp+0x84/0xc4 (P)
> [ 1.645471] __thermal_zone_get_temp+0x24/0x11c
> [ 1.656502] __thermal_zone_device_update+0x9c/0x52c
>
> Add the new ops member added in 7.0-rc1 for mt7987 too.
>
> Commit 6931d597c5ef ("thermal/drivers/mediatek/lvts: Make number of
> calibration offsets configurable") introduced field num_cal_offsets
> in lvts_data. Add this for mt7987 too.
>
> Fixes: 78c24e67d6f8 ("thermal/drivers/mediatek/lvts_thermal: Add mt7987 support")
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> drivers/thermal/mediatek/lvts_thermal.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c
> index a9617d5e0077..1224ce0c1507 100644
> --- a/drivers/thermal/mediatek/lvts_thermal.c
> +++ b/drivers/thermal/mediatek/lvts_thermal.c
> @@ -2026,6 +2026,8 @@ static const struct lvts_data mt7987_lvts_ap_data = {
> .temp_offset = LVTS_COEFF_B_MT7987,
> .gt_calib_bit_offset = 32,
> .def_calibration = 19380,
> + .num_cal_offsets = LVTS_NUM_CAL_OFFSETS_MT7988,
> + .ops = &lvts_platform_ops_mt7988,
> };
>
> static const struct lvts_data mt7988_lvts_ap_data = {
> --
> 2.43.0
>
regards Frank
^ permalink raw reply
* Re: [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking
From: kernel test robot @ 2026-03-26 16:40 UTC (permalink / raw)
To: Christian Loehle, arighi
Cc: oe-kbuild-all, peterz, vincent.guittot, dietmar.eggemann,
valentin.schneider, mingo, rostedt, segall, mgorman,
catalin.marinas, will, sudeep.holla, rafael, linux-pm,
linux-kernel, juri.lelli, kobak, fabecassis, Christian Loehle
In-Reply-To: <20260325181314.3875909-2-christian.loehle@arm.com>
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on arm64/for-next/core driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus peterz-queue/sched/core linus/master v7.0-rc5 next-20260325]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Loehle/sched-topology-Introduce-arch-hooks-for-asympacking/20260326-145644
base: tip/sched/core
patch link: https://lore.kernel.org/r/20260325181314.3875909-2-christian.loehle%40arm.com
patch subject: [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking
config: powerpc-randconfig-001-20260326 (https://download.01.org/0day-ci/archive/20260327/202603270017.gHZBIwsQ-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 10.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260327/202603270017.gHZBIwsQ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603270017.gHZBIwsQ-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/topology.h:30,
from include/linux/gfp.h:8,
from include/linux/sched/mm.h:9,
from arch/powerpc/kernel/smp.c:18:
>> include/linux/arch_topology.h:131:32: error: redefinition of 'topology_arch_asym_cpu_priority'
131 | #define arch_asym_cpu_priority topology_arch_asym_cpu_priority
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kernel/smp.c:1767:5: note: in expansion of macro 'arch_asym_cpu_priority'
1767 | int arch_asym_cpu_priority(int cpu)
| ^~~~~~~~~~~~~~~~~~~~~~
include/linux/arch_topology.h:132:19: note: previous definition of 'topology_arch_asym_cpu_priority' was here
132 | static inline int topology_arch_asym_cpu_priority(int cpu)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/topology_arch_asym_cpu_priority +131 include/linux/arch_topology.h
125
126 /*
127 * Architectures may override this to provide a custom CPU priority for
128 * asymmetric packing.
129 */
130 #ifndef arch_asym_cpu_priority
> 131 #define arch_asym_cpu_priority topology_arch_asym_cpu_priority
132 static inline int topology_arch_asym_cpu_priority(int cpu)
133 {
134 return -cpu;
135 }
136 #endif
137
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 0/2] Support BPF traversal of wakeup sources
From: Kumar Kartikeya Dwivedi @ 2026-03-26 16:30 UTC (permalink / raw)
To: Samuel Wu
Cc: Alexei Starovoitov, Puranjay Mohan, Rafael J. Wysocki, Len Brown,
Pavel Machek, Greg Kroah-Hartman, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Shuah Khan, Android Kernel Team, LKML, Linux Power Management,
driver-core, bpf, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAG2Kctqd4p4pJtH=tSfKT57qfecQrpcoYu3SsAzJ-zGEiYVSQA@mail.gmail.com>
On Thu, 26 Mar 2026 at 17:26, Samuel Wu <wusamuel@google.com> wrote:
>
> On Thu, Mar 26, 2026 at 8:02 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Mar 26, 2026 at 7:54 AM Kumar Kartikeya Dwivedi
> > <memxor@gmail.com> wrote:
> > >
> > > On Thu, 26 Mar 2026 at 13:20, Puranjay Mohan <puranjay@kernel.org> wrote:
> > > >
> > > > Samuel Wu <wusamuel@google.com> writes:
> > > >
> > > > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > > > wakeup_sources, and puts a config flag around the sysfs interface.
> > > > >
> > > > > Currently, a traversal of wakeup sources require going through
> > > > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > > > wakeup source also having multiple attributes. debugfs is unstable and
> > > > > insecure.
> > > > >
> > > > > Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> > > > > traverse the wakeup sources list. The head address of wakeup_sources can
> > > > > safely be resolved through BPF helper functions or variable attributes.
> > > > >
> > > > > On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> > > > > speedup (sampled 75 times in table below). For a device under load, the
> > > > > speedup is greater.
> > > > > +-------+----+----------+----------+
> > > > > | | n | AVG (ms) | STD (ms) |
> > > > > +-------+----+----------+----------+
> > > > > | sysfs | 75 | 44.9 | 12.6 |
> > > > > +-------+----+----------+----------+
> > > > > | BPF | 75 | 1.3 | 0.7 |
> > > > > +-------+----+----------+----------+
> > > > >
> > > > > The initial attempts for BPF traversal of wakeup_sources was with BPF
> > > > > iterators [1]. However, BPF already allows for traversing of a simple list
> > > > > with bpf_for(), and this current patchset has the added benefit of being
> > > > > ~2-3x more performant than BPF iterators.
> > > >
> > > > I left some inline comments on patch 1, but the high level concern is
> > > > that encoding the SRCU index into a fake pointer to get KF_ACQUIRE/
> > > > KF_RELEASE tracking is working against the verifier rather than with it.
> > > > Nothing actually prevents a BPF program from walking the list without
> > > > the lock, and the whole pointer encoding trick goes away if this is done
> > > > as an open-coded iterator instead.
> > >
> > > Which is fine, the critical section is only doing CO-RE accesses, and
> > > the SRCU lock is just to be able to read things in a valid state while
> > > walking the list. It is all best-effort.
> > > Open coded iterators was already explored as an option in earlier
> > > iterations of the series and discarded as no-go.
> >
> > kinda best-effort...
> > the way it's written bpf_wakeup_sources_get_head() returns
> > trusted list_head. It's then core-read-ed anyway.
> > Ideally it should be trusted only within that srcu CS
> > and invalidated by the verifier similar to KF_RCU_PROTECTED,
> > but that's bigger task.
> > Instead let's make bpf_wakeup_sources_get_head() return 'void *',
> > so it's clearly untrusted.
>
> Thanks all for the fruitful discussion; this is more rigorous. I'll
> update v3 so that `bpf_wakeup_sources_get_head()`'s return type is
> `void *` and I can add a corresponding selftest that directly
> dereferences the head and expects a verifier failure.
You could also use bpf_core_cast() instead of using macros to read
every field, should be equivalent. You may still need the macros for
bitfields but it should work otherwise.
^ permalink raw reply
* Re: [PATCH v2 0/2] Support BPF traversal of wakeup sources
From: Samuel Wu @ 2026-03-26 16:25 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Kumar Kartikeya Dwivedi, Puranjay Mohan, Rafael J. Wysocki,
Len Brown, Pavel Machek, Greg Kroah-Hartman, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Shuah Khan, Android Kernel Team, LKML, Linux Power Management,
driver-core, bpf, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAADnVQK252XxmxM3enS4wPREshTEawQKbChgN-teX3+wmxgdBQ@mail.gmail.com>
On Thu, Mar 26, 2026 at 8:02 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Mar 26, 2026 at 7:54 AM Kumar Kartikeya Dwivedi
> <memxor@gmail.com> wrote:
> >
> > On Thu, 26 Mar 2026 at 13:20, Puranjay Mohan <puranjay@kernel.org> wrote:
> > >
> > > Samuel Wu <wusamuel@google.com> writes:
> > >
> > > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > > wakeup_sources, and puts a config flag around the sysfs interface.
> > > >
> > > > Currently, a traversal of wakeup sources require going through
> > > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > > wakeup source also having multiple attributes. debugfs is unstable and
> > > > insecure.
> > > >
> > > > Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> > > > traverse the wakeup sources list. The head address of wakeup_sources can
> > > > safely be resolved through BPF helper functions or variable attributes.
> > > >
> > > > On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> > > > speedup (sampled 75 times in table below). For a device under load, the
> > > > speedup is greater.
> > > > +-------+----+----------+----------+
> > > > | | n | AVG (ms) | STD (ms) |
> > > > +-------+----+----------+----------+
> > > > | sysfs | 75 | 44.9 | 12.6 |
> > > > +-------+----+----------+----------+
> > > > | BPF | 75 | 1.3 | 0.7 |
> > > > +-------+----+----------+----------+
> > > >
> > > > The initial attempts for BPF traversal of wakeup_sources was with BPF
> > > > iterators [1]. However, BPF already allows for traversing of a simple list
> > > > with bpf_for(), and this current patchset has the added benefit of being
> > > > ~2-3x more performant than BPF iterators.
> > >
> > > I left some inline comments on patch 1, but the high level concern is
> > > that encoding the SRCU index into a fake pointer to get KF_ACQUIRE/
> > > KF_RELEASE tracking is working against the verifier rather than with it.
> > > Nothing actually prevents a BPF program from walking the list without
> > > the lock, and the whole pointer encoding trick goes away if this is done
> > > as an open-coded iterator instead.
> >
> > Which is fine, the critical section is only doing CO-RE accesses, and
> > the SRCU lock is just to be able to read things in a valid state while
> > walking the list. It is all best-effort.
> > Open coded iterators was already explored as an option in earlier
> > iterations of the series and discarded as no-go.
>
> kinda best-effort...
> the way it's written bpf_wakeup_sources_get_head() returns
> trusted list_head. It's then core-read-ed anyway.
> Ideally it should be trusted only within that srcu CS
> and invalidated by the verifier similar to KF_RCU_PROTECTED,
> but that's bigger task.
> Instead let's make bpf_wakeup_sources_get_head() return 'void *',
> so it's clearly untrusted.
Thanks all for the fruitful discussion; this is more rigorous. I'll
update v3 so that `bpf_wakeup_sources_get_head()`'s return type is
`void *` and I can add a corresponding selftest that directly
dereferences the head and expects a verifier failure.
^ permalink raw reply
* Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry
From: Andrea Righi @ 2026-03-26 16:00 UTC (permalink / raw)
To: Christian Loehle
Cc: Vincent Guittot, peterz, dietmar.eggemann, valentin.schneider,
mingo, rostedt, segall, mgorman, catalin.marinas, will,
sudeep.holla, rafael, linux-pm, linux-kernel, juri.lelli, kobak,
fabecassis
In-Reply-To: <3a1ecb19-779a-418a-bc87-033d16905b46@arm.com>
On Thu, Mar 26, 2026 at 03:55:54PM +0000, Christian Loehle wrote:
> On 3/26/26 13:45, Andrea Righi wrote:
> > On Thu, Mar 26, 2026 at 02:04:42PM +0100, Vincent Guittot wrote:
> >> On Thu, 26 Mar 2026 at 10:24, Christian Loehle <christian.loehle@arm.com> wrote:
> >>>
> >>> On 3/26/26 08:24, Vincent Guittot wrote:
> >>>> On Thu, 26 Mar 2026 at 09:16, Christian Loehle <christian.loehle@arm.com> wrote:
> >>>>>
> >>>>> On 3/26/26 07:53, Vincent Guittot wrote:
> >>>>>> On Wed, 25 Mar 2026 at 19:13, Christian Loehle <christian.loehle@arm.com> wrote:
> >>>>>>>
> >>>>>>> The scheduler currently handles CPU performance asymmetry via either:
> >>>>>>>
> >>>>>>> - SD_ASYM_PACKING: simple priority-based task placement (x86 ITMT)
> >>>>>>> - SD_ASYM_CPUCAPACITY: capacity-aware scheduling
> >>>>>>>
> >>>>>>> On arm64, capacity-aware scheduling is used for any detected capacity
> >>>>>>> differences.
> >>>>>>>
> >>>>>>> Some systems expose small per-CPU performance differences via CPPC
> >>>>>>> highest_perf (e.g. due to chip binning), resulting in slightly different
> >>>>>>> capacities (<~5%). These differences are sufficient to trigger
> >>>>>>> SD_ASYM_CPUCAPACITY, even though the system is otherwise effectively
> >>>>>>> symmetric.
> >>>>>>>
> >>>>>>> For such small deltas, capacity-aware scheduling is unnecessarily
> >>>>>>> complex. A simpler priority-based approach, similar to x86 ITMT, is
> >>>>>>> sufficient.
> >>>>>>
> >>>>>> I'm not convinced that moving to SD_ASYM_PACKING is the right way to
> >>>>>> move forward.
> >>>>>> t
> >>>>>> 1st of all, do you target all kind of system or only SMT? It's not
> >>>>>> clear in your cover letter
> >>>>>
> >>>>> AFAIK only Andrea has access to an unreleased asymmetric SMT system,
> >>>>> I haven't done any tests on such a system (as the cover-letter mentions
> >>>>> under RFT section).
> >>>>>
> >>>>>>
> >>>>>> Moving on asym pack for !SMT doesn't make sense to me. If you don't
> >>>>>> want EAS enabled, you can disable it with
> >>>>>> /proc/sys/kernel/sched_energy_aware
> >>>>>
> >>>>> Sorry, what's EAS got to do with it? The system I care about here
> >>>>> (primarily nvidia grace) has no EM.
> >>>>
> >>>> I tried to understand the end goal of this patch
> >>>>
> >>>> SD_ASYM_CPUCAPACITY works fine with !SMT system so why enabling
> >>>> SD_ASYM_PACKING for <5% diff ?
> >>>>
> >>>> That doesn't make sense to me
> >>> I don't know if "works fine" describes the situation accurately.
> >>> I guess I should've included the context in the cover letter, but you
> >>> are aware of them (you've replied to them anyway):
> >>> https://lore.kernel.org/lkml/20260324005509.1134981-1-arighi@nvidia.com/
> >>> https://lore.kernel.org/lkml/20260318092214.130908-1-arighi@nvidia.com/
> >>>
> >>> Andrea sees an improvement even when force-equalizing CPUs to remove
> >>> SD_ASYM_CPUCAPACITY, so I'd argue it doesn't "work fine" on these platforms.
> >>
> >> IIUC this was for SMT systems not for !SMT ones but I might have
> >> missed some emails in the thread.
> >
> > Right, the issue I'm trying to solve is SD_ASYM_CPUCAPACITY + SMT. Removing
> > SD_ASYM_CPUCAPACITY from the equation fixes my issue, because we fall back
> > into the regular idle CPU selection policy, which avoids allocating both
> > SMT siblings when possible.
> >
> > Thanks,
> > -Andrea
>
> Could you also report how Grace baseline vs ASYM_PACKING works for your
> benchmark? (or Vera nosmt)
>
Sure, I'll try testing both and report back.
-Andrea
^ permalink raw reply
* Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry
From: Christian Loehle @ 2026-03-26 15:55 UTC (permalink / raw)
To: Andrea Righi, Vincent Guittot
Cc: peterz, dietmar.eggemann, valentin.schneider, mingo, rostedt,
segall, mgorman, catalin.marinas, will, sudeep.holla, rafael,
linux-pm, linux-kernel, juri.lelli, kobak, fabecassis
In-Reply-To: <acU4ZIiGuiDvSL1b@gpd4>
On 3/26/26 13:45, Andrea Righi wrote:
> On Thu, Mar 26, 2026 at 02:04:42PM +0100, Vincent Guittot wrote:
>> On Thu, 26 Mar 2026 at 10:24, Christian Loehle <christian.loehle@arm.com> wrote:
>>>
>>> On 3/26/26 08:24, Vincent Guittot wrote:
>>>> On Thu, 26 Mar 2026 at 09:16, Christian Loehle <christian.loehle@arm.com> wrote:
>>>>>
>>>>> On 3/26/26 07:53, Vincent Guittot wrote:
>>>>>> On Wed, 25 Mar 2026 at 19:13, Christian Loehle <christian.loehle@arm.com> wrote:
>>>>>>>
>>>>>>> The scheduler currently handles CPU performance asymmetry via either:
>>>>>>>
>>>>>>> - SD_ASYM_PACKING: simple priority-based task placement (x86 ITMT)
>>>>>>> - SD_ASYM_CPUCAPACITY: capacity-aware scheduling
>>>>>>>
>>>>>>> On arm64, capacity-aware scheduling is used for any detected capacity
>>>>>>> differences.
>>>>>>>
>>>>>>> Some systems expose small per-CPU performance differences via CPPC
>>>>>>> highest_perf (e.g. due to chip binning), resulting in slightly different
>>>>>>> capacities (<~5%). These differences are sufficient to trigger
>>>>>>> SD_ASYM_CPUCAPACITY, even though the system is otherwise effectively
>>>>>>> symmetric.
>>>>>>>
>>>>>>> For such small deltas, capacity-aware scheduling is unnecessarily
>>>>>>> complex. A simpler priority-based approach, similar to x86 ITMT, is
>>>>>>> sufficient.
>>>>>>
>>>>>> I'm not convinced that moving to SD_ASYM_PACKING is the right way to
>>>>>> move forward.
>>>>>> t
>>>>>> 1st of all, do you target all kind of system or only SMT? It's not
>>>>>> clear in your cover letter
>>>>>
>>>>> AFAIK only Andrea has access to an unreleased asymmetric SMT system,
>>>>> I haven't done any tests on such a system (as the cover-letter mentions
>>>>> under RFT section).
>>>>>
>>>>>>
>>>>>> Moving on asym pack for !SMT doesn't make sense to me. If you don't
>>>>>> want EAS enabled, you can disable it with
>>>>>> /proc/sys/kernel/sched_energy_aware
>>>>>
>>>>> Sorry, what's EAS got to do with it? The system I care about here
>>>>> (primarily nvidia grace) has no EM.
>>>>
>>>> I tried to understand the end goal of this patch
>>>>
>>>> SD_ASYM_CPUCAPACITY works fine with !SMT system so why enabling
>>>> SD_ASYM_PACKING for <5% diff ?
>>>>
>>>> That doesn't make sense to me
>>> I don't know if "works fine" describes the situation accurately.
>>> I guess I should've included the context in the cover letter, but you
>>> are aware of them (you've replied to them anyway):
>>> https://lore.kernel.org/lkml/20260324005509.1134981-1-arighi@nvidia.com/
>>> https://lore.kernel.org/lkml/20260318092214.130908-1-arighi@nvidia.com/
>>>
>>> Andrea sees an improvement even when force-equalizing CPUs to remove
>>> SD_ASYM_CPUCAPACITY, so I'd argue it doesn't "work fine" on these platforms.
>>
>> IIUC this was for SMT systems not for !SMT ones but I might have
>> missed some emails in the thread.
>
> Right, the issue I'm trying to solve is SD_ASYM_CPUCAPACITY + SMT. Removing
> SD_ASYM_CPUCAPACITY from the equation fixes my issue, because we fall back
> into the regular idle CPU selection policy, which avoids allocating both
> SMT siblings when possible.
>
> Thanks,
> -Andrea
Could you also report how Grace baseline vs ASYM_PACKING works for your
benchmark? (or Vera nosmt)
^ permalink raw reply
* Re: [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking
From: kernel test robot @ 2026-03-26 15:47 UTC (permalink / raw)
To: Christian Loehle, arighi
Cc: oe-kbuild-all, peterz, vincent.guittot, dietmar.eggemann,
valentin.schneider, mingo, rostedt, segall, mgorman,
catalin.marinas, will, sudeep.holla, rafael, linux-pm,
linux-kernel, juri.lelli, kobak, fabecassis, Christian Loehle
In-Reply-To: <20260325181314.3875909-4-christian.loehle@arm.com>
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on arm64/for-next/core driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus peterz-queue/sched/core linus/master v7.0-rc5 next-20260325]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Loehle/sched-topology-Introduce-arch-hooks-for-asympacking/20260326-145644
base: tip/sched/core
patch link: https://lore.kernel.org/r/20260325181314.3875909-4-christian.loehle%40arm.com
patch subject: [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking
config: parisc-allnoconfig (https://download.01.org/0day-ci/archive/20260326/202603262307.63Wed8OI-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603262307.63Wed8OI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603262307.63Wed8OI-lkp@intel.com/
All errors (new ones prefixed by >>):
hppa-linux-ld: kernel/sched/build_utility.o: in function `sd_init.constprop.0':
>> (.text+0x17b8): undefined reference to `arch_sched_asym_flags'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking
From: kernel test robot @ 2026-03-26 15:47 UTC (permalink / raw)
To: Christian Loehle, arighi
Cc: oe-kbuild-all, peterz, vincent.guittot, dietmar.eggemann,
valentin.schneider, mingo, rostedt, segall, mgorman,
catalin.marinas, will, sudeep.holla, rafael, linux-pm,
linux-kernel, juri.lelli, kobak, fabecassis, Christian Loehle
In-Reply-To: <20260325181314.3875909-4-christian.loehle@arm.com>
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on arm64/for-next/core driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus peterz-queue/sched/core linus/master v7.0-rc5 next-20260325]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Loehle/sched-topology-Introduce-arch-hooks-for-asympacking/20260326-145644
base: tip/sched/core
patch link: https://lore.kernel.org/r/20260325181314.3875909-4-christian.loehle%40arm.com
patch subject: [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking
config: openrisc-allnoconfig (https://download.01.org/0day-ci/archive/20260326/202603262311.bSaX71dF-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603262311.bSaX71dF-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603262311.bSaX71dF-lkp@intel.com/
All errors (new ones prefixed by >>):
or1k-linux-ld: kernel/sched/build_utility.o: in function `sd_init.constprop.0':
build_utility.c:(.text+0x1840): undefined reference to `arch_sched_asym_flags'
>> build_utility.c:(.text+0x1840): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `arch_sched_asym_flags'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Catalin Marinas @ 2026-03-26 15:39 UTC (permalink / raw)
To: David Laight
Cc: Ankur Arora, Andrew Morton, linux-kernel, linux-arch,
linux-arm-kernel, linux-pm, bpf, arnd, will, peterz, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1,
xueshuai, rdunlap, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <20260325202357.3e203314@pumpkin>
On Wed, Mar 25, 2026 at 08:23:57PM +0000, David Laight wrote:
> On Wed, 25 Mar 2026 16:32:49 +0000
> Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> > On Wed, Mar 25, 2026 at 03:42:10PM +0000, David Laight wrote:
> ...
> > > Looking at the code I think the "sevl; wfe" pair should be higher up.
> >
> > Yes, I replied to your other message. We could move it higher indeed,
> > before the condition check, but I can't get my head around the ordering.
> > Can need_resched() check be speculated before the WFE? I need to think
> > some more.
>
> I don't think speculation can matter.
> Both SEVL and WFE must be serialised against any other instructions
> that can change the event flag (as well as each other) otherwise
> everything is broken.
Welcome to the Arm memory model. We don't have any guarantee that an LDR
will only access memory after SEVL+WFE. They are not serialising.
> Apart from that it doesn't matter, what matters is the instruction
> boundary the interrupt happens at.
True. If an interrupt is taken before the LDR (that would be a
need_resched() check for example), then a prior WFE would not matter.
This won't work if we replace the IPI with a SEV though (suggested
somewhere in this thread).
> Actually both SEVL and WFE may be synchronising instructions and very slow.
Most likely not.
> So you may not want to put them in the fast path where the condition
> is true on entry (or even true after a retry).
> So the code might have to look like:
> for (;;) {
> VAL = mem;
If we only waited on the location passed to LDXR, things would have been
much simpler. But the osq_lock() also wants to wait on the TIF flags via
need_resched() (and vcpu_is_preempted()).
> if (cond(VAL)) return;
So the cond(VAL) here is actually a series of other memory loads
unrelated to 'mem'
> SEVL; WFE;
> if (cond(VAL)) return;
I think this will work in principle even if 'cond' accesses other memory
locations, though I wouldn't bother with an additional 'cond' call, I'd
expect SEVL+WFE to be mostly NOPs. However, 'cond' must not set a local
event, otherwise the power saving on waiting is gone.
> v1 = LDX(mem);
> if (v1 == VAL)
> WFE;
> }
I think it's cleaner to use Ankur's timeout API here for the very rare
case where an IPI hits at the wrong time. We then keep
smp_cond_load_relaxed() intact as it's really not meant to wait on
multiple memory locations to change. Any changes of
smp_cond_load_relaxed() with moving the WFE around are just hacks, not
the intended use of this API.
--
Catalin
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS 3d6125a4ea0e7ef1b11fa4dbf7e98831ef166613
From: kernel test robot @ 2026-03-26 15:35 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 3d6125a4ea0e7ef1b11fa4dbf7e98831ef166613 Merge branch 'pm-cpufreq' into bleeding-edge
elapsed time: 1233m
configs tested: 156
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260326 gcc-13.4.0
arc randconfig-002-20260326 gcc-8.5.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260326 clang-23
arm randconfig-002-20260326 gcc-11.5.0
arm randconfig-003-20260326 gcc-10.5.0
arm randconfig-004-20260326 gcc-12.5.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260326 clang-19
arm64 randconfig-002-20260326 clang-23
arm64 randconfig-003-20260326 gcc-13.4.0
arm64 randconfig-004-20260326 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260326 gcc-13.4.0
csky randconfig-002-20260326 gcc-9.5.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260326 clang-23
hexagon randconfig-002-20260326 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260326 gcc-14
i386 buildonly-randconfig-002-20260326 clang-20
i386 buildonly-randconfig-003-20260326 gcc-14
i386 buildonly-randconfig-004-20260326 clang-20
i386 buildonly-randconfig-005-20260326 gcc-14
i386 buildonly-randconfig-006-20260326 clang-20
i386 defconfig clang-20
i386 randconfig-001-20260326 clang-20
i386 randconfig-002-20260326 gcc-14
i386 randconfig-003-20260326 clang-20
i386 randconfig-004-20260326 gcc-14
i386 randconfig-005-20260326 gcc-14
i386 randconfig-006-20260326 clang-20
i386 randconfig-007-20260326 clang-20
i386 randconfig-011-20260326 gcc-14
i386 randconfig-012-20260326 gcc-14
i386 randconfig-013-20260326 gcc-14
i386 randconfig-014-20260326 gcc-14
i386 randconfig-015-20260326 clang-20
i386 randconfig-016-20260326 clang-20
i386 randconfig-017-20260326 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch defconfig clang-19
loongarch randconfig-001-20260326 clang-18
loongarch randconfig-002-20260326 gcc-14.3.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260326 gcc-9.5.0
nios2 randconfig-002-20260326 gcc-8.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260326 gcc-12.5.0
parisc randconfig-002-20260326 gcc-11.5.0
parisc64 defconfig gcc-15.2.0
powerpc akebono_defconfig clang-23
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260326 gcc-10.5.0
powerpc randconfig-002-20260326 clang-19
powerpc64 randconfig-001-20260326 gcc-8.5.0
powerpc64 randconfig-002-20260326 clang-19
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260326 gcc-10.5.0
riscv randconfig-002-20260326 gcc-8.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260326 gcc-13.4.0
s390 randconfig-002-20260326 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260326 gcc-15.2.0
sh randconfig-002-20260326 gcc-15.2.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260326 gcc-8.5.0
sparc randconfig-002-20260326 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260326 clang-23
sparc64 randconfig-002-20260326 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260326 gcc-14
um randconfig-002-20260326 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260326 gcc-14
x86_64 buildonly-randconfig-002-20260326 gcc-14
x86_64 buildonly-randconfig-003-20260326 clang-20
x86_64 buildonly-randconfig-004-20260326 clang-20
x86_64 buildonly-randconfig-005-20260326 gcc-14
x86_64 buildonly-randconfig-006-20260326 gcc-12
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260326 gcc-14
x86_64 randconfig-002-20260326 gcc-14
x86_64 randconfig-004-20260326 gcc-14
x86_64 randconfig-005-20260326 clang-20
x86_64 randconfig-011-20260326 gcc-14
x86_64 randconfig-012-20260326 gcc-14
x86_64 randconfig-013-20260326 gcc-14
x86_64 randconfig-014-20260326 gcc-12
x86_64 randconfig-015-20260326 gcc-14
x86_64 randconfig-016-20260326 gcc-12
x86_64 randconfig-071-20260326 clang-20
x86_64 randconfig-072-20260326 gcc-14
x86_64 randconfig-073-20260326 gcc-14
x86_64 randconfig-074-20260326 gcc-14
x86_64 randconfig-075-20260326 clang-20
x86_64 randconfig-076-20260326 gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa randconfig-001-20260326 gcc-11.5.0
xtensa randconfig-002-20260326 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking
From: kernel test robot @ 2026-03-26 15:26 UTC (permalink / raw)
To: Christian Loehle, arighi
Cc: oe-kbuild-all, peterz, vincent.guittot, dietmar.eggemann,
valentin.schneider, mingo, rostedt, segall, mgorman,
catalin.marinas, will, sudeep.holla, rafael, linux-pm,
linux-kernel, juri.lelli, kobak, fabecassis, Christian Loehle
In-Reply-To: <20260325181314.3875909-2-christian.loehle@arm.com>
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on arm64/for-next/core driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus peterz-queue/sched/core next-20260325]
[cannot apply to linus/master v6.16-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Loehle/sched-topology-Introduce-arch-hooks-for-asympacking/20260326-145644
base: tip/sched/core
patch link: https://lore.kernel.org/r/20260325181314.3875909-2-christian.loehle%40arm.com
patch subject: [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260326/202603261609.fazAo3mx-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603261609.fazAo3mx-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603261609.fazAo3mx-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/topology.h:30,
from include/linux/sched/topology.h:5,
from include/linux/cpuset.h:13,
from arch/x86/kernel/itmt.c:21:
>> include/linux/arch_topology.h:131:32: error: redefinition of 'topology_arch_asym_cpu_priority'
131 | #define arch_asym_cpu_priority topology_arch_asym_cpu_priority
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/kernel/itmt.c:168:5: note: in expansion of macro 'arch_asym_cpu_priority'
168 | int arch_asym_cpu_priority(int cpu)
| ^~~~~~~~~~~~~~~~~~~~~~
include/linux/arch_topology.h:132:19: note: previous definition of 'topology_arch_asym_cpu_priority' with type 'int(int)'
132 | static inline int topology_arch_asym_cpu_priority(int cpu)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/topology_arch_asym_cpu_priority +131 include/linux/arch_topology.h
125
126 /*
127 * Architectures may override this to provide a custom CPU priority for
128 * asymmetric packing.
129 */
130 #ifndef arch_asym_cpu_priority
> 131 #define arch_asym_cpu_priority topology_arch_asym_cpu_priority
132 static inline int topology_arch_asym_cpu_priority(int cpu)
133 {
134 return -cpu;
135 }
136 #endif
137
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [char-misc v3] mei: me: reduce the scope on unexpected reset
From: Alexander Usyskin @ 2026-03-26 14:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Menachem Adin, Alexander Usyskin, Rafael J . Wysocki, linux-pm,
linux-kernel, Todd Brandt
After commit 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected")
some devices started to show long resume times (5-7 seconds).
This happens as mei falsely detects unready hardware,
starts parallel link reset flow and triggers link reset timeouts
in the resume callback.
Address it by performing detection of unready hardware only
when driver is in the ENABLED state instead of blacklisting
states as done in the original patch.
Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221023
Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Fixes: 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected")
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
---
V3: reword commit message, add Rafael and PM list
V2: rebase over v7.0-rc4
drivers/misc/mei/hw-me.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index d4612c659784..1e4a41ac428f 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -1337,19 +1337,13 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* check if we need to start the dev */
if (!mei_host_is_ready(dev)) {
if (mei_hw_is_ready(dev)) {
- /* synchronized by dev mutex */
- if (waitqueue_active(&dev->wait_hw_ready)) {
- dev_dbg(&dev->dev, "we need to start the dev.\n");
- dev->recvd_hw_ready = true;
- wake_up(&dev->wait_hw_ready);
- } else if (dev->dev_state != MEI_DEV_UNINITIALIZED &&
- dev->dev_state != MEI_DEV_POWERING_DOWN &&
- dev->dev_state != MEI_DEV_POWER_DOWN) {
+ if (dev->dev_state == MEI_DEV_ENABLED) {
dev_dbg(&dev->dev, "Force link reset.\n");
schedule_work(&dev->reset_work);
} else {
- dev_dbg(&dev->dev, "Ignore this interrupt in state = %d\n",
- dev->dev_state);
+ dev_dbg(&dev->dev, "we need to start the dev.\n");
+ dev->recvd_hw_ready = true;
+ wake_up(&dev->wait_hw_ready);
}
} else {
dev_dbg(&dev->dev, "Spurious Interrupt\n");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 0/2] Support BPF traversal of wakeup sources
From: Alexei Starovoitov @ 2026-03-26 15:01 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi
Cc: Puranjay Mohan, Samuel Wu, Rafael J. Wysocki, Len Brown,
Pavel Machek, Greg Kroah-Hartman, Danilo Krummrich,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Shuah Khan, Android Kernel Team, LKML, Linux Power Management,
driver-core, bpf, open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <CAP01T74KNVT2SVRR+XPbFb1vy85W=Jkp4_yD6xvTSg2avQo8AQ@mail.gmail.com>
On Thu, Mar 26, 2026 at 7:54 AM Kumar Kartikeya Dwivedi
<memxor@gmail.com> wrote:
>
> On Thu, 26 Mar 2026 at 13:20, Puranjay Mohan <puranjay@kernel.org> wrote:
> >
> > Samuel Wu <wusamuel@google.com> writes:
> >
> > > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > > wakeup_sources, and puts a config flag around the sysfs interface.
> > >
> > > Currently, a traversal of wakeup sources require going through
> > > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > > wakeup source also having multiple attributes. debugfs is unstable and
> > > insecure.
> > >
> > > Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> > > traverse the wakeup sources list. The head address of wakeup_sources can
> > > safely be resolved through BPF helper functions or variable attributes.
> > >
> > > On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> > > speedup (sampled 75 times in table below). For a device under load, the
> > > speedup is greater.
> > > +-------+----+----------+----------+
> > > | | n | AVG (ms) | STD (ms) |
> > > +-------+----+----------+----------+
> > > | sysfs | 75 | 44.9 | 12.6 |
> > > +-------+----+----------+----------+
> > > | BPF | 75 | 1.3 | 0.7 |
> > > +-------+----+----------+----------+
> > >
> > > The initial attempts for BPF traversal of wakeup_sources was with BPF
> > > iterators [1]. However, BPF already allows for traversing of a simple list
> > > with bpf_for(), and this current patchset has the added benefit of being
> > > ~2-3x more performant than BPF iterators.
> >
> > I left some inline comments on patch 1, but the high level concern is
> > that encoding the SRCU index into a fake pointer to get KF_ACQUIRE/
> > KF_RELEASE tracking is working against the verifier rather than with it.
> > Nothing actually prevents a BPF program from walking the list without
> > the lock, and the whole pointer encoding trick goes away if this is done
> > as an open-coded iterator instead.
>
> Which is fine, the critical section is only doing CO-RE accesses, and
> the SRCU lock is just to be able to read things in a valid state while
> walking the list. It is all best-effort.
> Open coded iterators was already explored as an option in earlier
> iterations of the series and discarded as no-go.
kinda best-effort...
the way it's written bpf_wakeup_sources_get_head() returns
trusted list_head. It's then core-read-ed anyway.
Ideally it should be trusted only within that srcu CS
and invalidated by the verifier similar to KF_RCU_PROTECTED,
but that's bigger task.
Instead let's make bpf_wakeup_sources_get_head() return 'void *',
so it's clearly untrusted.
^ permalink raw reply
* Re: [PATCH v2 0/2] Support BPF traversal of wakeup sources
From: Kumar Kartikeya Dwivedi @ 2026-03-26 14:53 UTC (permalink / raw)
To: Puranjay Mohan
Cc: Samuel Wu, Rafael J. Wysocki, Len Brown, Pavel Machek,
Greg Kroah-Hartman, Danilo Krummrich, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Shuah Khan,
kernel-team, linux-kernel, linux-pm, driver-core, bpf,
linux-kselftest
In-Reply-To: <m2v7eig4ue.fsf@kernel.org>
On Thu, 26 Mar 2026 at 13:20, Puranjay Mohan <puranjay@kernel.org> wrote:
>
> Samuel Wu <wusamuel@google.com> writes:
>
> > This patchset adds requisite kfuncs for BPF programs to safely traverse
> > wakeup_sources, and puts a config flag around the sysfs interface.
> >
> > Currently, a traversal of wakeup sources require going through
> > /sys/class/wakeup/* or /d/wakeup_sources/*. The repeated syscalls to query
> > sysfs is inefficient, as there can be hundreds of wakeup_sources, with each
> > wakeup source also having multiple attributes. debugfs is unstable and
> > insecure.
> >
> > Adding kfuncs to lock/unlock wakeup sources allows BPF program to safely
> > traverse the wakeup sources list. The head address of wakeup_sources can
> > safely be resolved through BPF helper functions or variable attributes.
> >
> > On a quiescent Pixel 6 traversing 150 wakeup_sources, I am seeing ~34x
> > speedup (sampled 75 times in table below). For a device under load, the
> > speedup is greater.
> > +-------+----+----------+----------+
> > | | n | AVG (ms) | STD (ms) |
> > +-------+----+----------+----------+
> > | sysfs | 75 | 44.9 | 12.6 |
> > +-------+----+----------+----------+
> > | BPF | 75 | 1.3 | 0.7 |
> > +-------+----+----------+----------+
> >
> > The initial attempts for BPF traversal of wakeup_sources was with BPF
> > iterators [1]. However, BPF already allows for traversing of a simple list
> > with bpf_for(), and this current patchset has the added benefit of being
> > ~2-3x more performant than BPF iterators.
>
> I left some inline comments on patch 1, but the high level concern is
> that encoding the SRCU index into a fake pointer to get KF_ACQUIRE/
> KF_RELEASE tracking is working against the verifier rather than with it.
> Nothing actually prevents a BPF program from walking the list without
> the lock, and the whole pointer encoding trick goes away if this is done
> as an open-coded iterator instead.
Which is fine, the critical section is only doing CO-RE accesses, and
the SRCU lock is just to be able to read things in a valid state while
walking the list. It is all best-effort.
Open coded iterators was already explored as an option in earlier
iterations of the series and discarded as no-go.
>
> Thanks,
> Puranjay
^ permalink raw reply
* Re: [Pre-CfP] LPC2026: Power management and thermal control micro-conference
From: Rafael J. Wysocki @ 2026-03-26 14:38 UTC (permalink / raw)
To: Linux PM
Cc: Daniel Lezcano, Lukasz Luba, Morten Rasmussen, Sudeep Holla,
Ulf Hansson, Christian Loehle, Artem Bityutskiy, Ricardo Neri,
Srinivas Pandruvada, Viresh Kumar, Pierre Gondois,
Dietmar Eggemann, Mario Limonciello, Shenoy, Gautham Ranjal
In-Reply-To: <CAJZ5v0jp-xWc_7Njjsva3EBhJXM31XVBpSspSkTd7FJ0wz1ezQ@mail.gmail.com>
+Mario and Gautham
On Thu, Mar 26, 2026 at 3:35 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> Hi All,
>
> I'm looking for topic suggestions to be included in the power
> management and thermal control micro-conference submission for
> LPC2026. The deadline for submitting LPC u-conf proposals is April
> 23, so if there are any topics you'd like to be covered, please let me
> know within the next 2 weeks.
>
> Thanks, Rafael
^ permalink raw reply
* [Pre-CfP] LPC2026: Power management and thermal control micro-conference
From: Rafael J. Wysocki @ 2026-03-26 14:35 UTC (permalink / raw)
To: Linux PM
Cc: Daniel Lezcano, Lukasz Luba, Morten Rasmussen, Sudeep Holla,
Ulf Hansson, Christian Loehle, Artem Bityutskiy, Ricardo Neri,
Srinivas Pandruvada, Viresh Kumar, Pierre Gondois,
Dietmar Eggemann
Hi All,
I'm looking for topic suggestions to be included in the power
management and thermal control micro-conference submission for
LPC2026. The deadline for submitting LPC u-conf proposals is April
23, so if there are any topics you'd like to be covered, please let me
know within the next 2 weeks.
Thanks, Rafael
^ permalink raw reply
* Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry
From: Andrea Righi @ 2026-03-26 13:45 UTC (permalink / raw)
To: Vincent Guittot
Cc: Christian Loehle, peterz, dietmar.eggemann, valentin.schneider,
mingo, rostedt, segall, mgorman, catalin.marinas, will,
sudeep.holla, rafael, linux-pm, linux-kernel, juri.lelli, kobak,
fabecassis
In-Reply-To: <CAKfTPtAQynr=khJk4amqR2m9bV5gnfi_RMkZj=zs0=gpUFr44w@mail.gmail.com>
On Thu, Mar 26, 2026 at 02:04:42PM +0100, Vincent Guittot wrote:
> On Thu, 26 Mar 2026 at 10:24, Christian Loehle <christian.loehle@arm.com> wrote:
> >
> > On 3/26/26 08:24, Vincent Guittot wrote:
> > > On Thu, 26 Mar 2026 at 09:16, Christian Loehle <christian.loehle@arm.com> wrote:
> > >>
> > >> On 3/26/26 07:53, Vincent Guittot wrote:
> > >>> On Wed, 25 Mar 2026 at 19:13, Christian Loehle <christian.loehle@arm.com> wrote:
> > >>>>
> > >>>> The scheduler currently handles CPU performance asymmetry via either:
> > >>>>
> > >>>> - SD_ASYM_PACKING: simple priority-based task placement (x86 ITMT)
> > >>>> - SD_ASYM_CPUCAPACITY: capacity-aware scheduling
> > >>>>
> > >>>> On arm64, capacity-aware scheduling is used for any detected capacity
> > >>>> differences.
> > >>>>
> > >>>> Some systems expose small per-CPU performance differences via CPPC
> > >>>> highest_perf (e.g. due to chip binning), resulting in slightly different
> > >>>> capacities (<~5%). These differences are sufficient to trigger
> > >>>> SD_ASYM_CPUCAPACITY, even though the system is otherwise effectively
> > >>>> symmetric.
> > >>>>
> > >>>> For such small deltas, capacity-aware scheduling is unnecessarily
> > >>>> complex. A simpler priority-based approach, similar to x86 ITMT, is
> > >>>> sufficient.
> > >>>
> > >>> I'm not convinced that moving to SD_ASYM_PACKING is the right way to
> > >>> move forward.
> > >>> t
> > >>> 1st of all, do you target all kind of system or only SMT? It's not
> > >>> clear in your cover letter
> > >>
> > >> AFAIK only Andrea has access to an unreleased asymmetric SMT system,
> > >> I haven't done any tests on such a system (as the cover-letter mentions
> > >> under RFT section).
> > >>
> > >>>
> > >>> Moving on asym pack for !SMT doesn't make sense to me. If you don't
> > >>> want EAS enabled, you can disable it with
> > >>> /proc/sys/kernel/sched_energy_aware
> > >>
> > >> Sorry, what's EAS got to do with it? The system I care about here
> > >> (primarily nvidia grace) has no EM.
> > >
> > > I tried to understand the end goal of this patch
> > >
> > > SD_ASYM_CPUCAPACITY works fine with !SMT system so why enabling
> > > SD_ASYM_PACKING for <5% diff ?
> > >
> > > That doesn't make sense to me
> > I don't know if "works fine" describes the situation accurately.
> > I guess I should've included the context in the cover letter, but you
> > are aware of them (you've replied to them anyway):
> > https://lore.kernel.org/lkml/20260324005509.1134981-1-arighi@nvidia.com/
> > https://lore.kernel.org/lkml/20260318092214.130908-1-arighi@nvidia.com/
> >
> > Andrea sees an improvement even when force-equalizing CPUs to remove
> > SD_ASYM_CPUCAPACITY, so I'd argue it doesn't "work fine" on these platforms.
>
> IIUC this was for SMT systems not for !SMT ones but I might have
> missed some emails in the thread.
Right, the issue I'm trying to solve is SD_ASYM_CPUCAPACITY + SMT. Removing
SD_ASYM_CPUCAPACITY from the equation fixes my issue, because we fall back
into the regular idle CPU selection policy, which avoids allocating both
SMT siblings when possible.
Thanks,
-Andrea
^ permalink raw reply
* Re: [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking
From: kernel test robot @ 2026-03-26 13:23 UTC (permalink / raw)
To: Christian Loehle, arighi
Cc: llvm, oe-kbuild-all, peterz, vincent.guittot, dietmar.eggemann,
valentin.schneider, mingo, rostedt, segall, mgorman,
catalin.marinas, will, sudeep.holla, rafael, linux-pm,
linux-kernel, juri.lelli, kobak, fabecassis, Christian Loehle
In-Reply-To: <20260325181314.3875909-2-christian.loehle@arm.com>
Hi Christian,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on arm64/for-next/core driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus peterz-queue/sched/core linus/master v7.0-rc5 next-20260325]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Loehle/sched-topology-Introduce-arch-hooks-for-asympacking/20260326-145644
base: tip/sched/core
patch link: https://lore.kernel.org/r/20260325181314.3875909-2-christian.loehle%40arm.com
patch subject: [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260326/202603261419.mAKkKckS-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603261419.mAKkKckS-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603261419.mAKkKckS-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/x86/kernel/itmt.c:168:5: error: redefinition of 'topology_arch_asym_cpu_priority'
168 | int arch_asym_cpu_priority(int cpu)
| ^
include/linux/arch_topology.h:131:32: note: expanded from macro 'arch_asym_cpu_priority'
131 | #define arch_asym_cpu_priority topology_arch_asym_cpu_priority
| ^
include/linux/arch_topology.h:132:19: note: previous definition is here
132 | static inline int topology_arch_asym_cpu_priority(int cpu)
| ^
1 error generated.
vim +/topology_arch_asym_cpu_priority +168 arch/x86/kernel/itmt.c
5e76b2ab36b40c Tim Chen 2016-11-22 167
5e76b2ab36b40c Tim Chen 2016-11-22 @168 int arch_asym_cpu_priority(int cpu)
5e76b2ab36b40c Tim Chen 2016-11-22 169 {
5e76b2ab36b40c Tim Chen 2016-11-22 170 return per_cpu(sched_core_priority, cpu);
5e76b2ab36b40c Tim Chen 2016-11-22 171 }
5e76b2ab36b40c Tim Chen 2016-11-22 172
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 2/2] cpufreq: Pass the policy to cpufreq_driver->adjust_perf()
From: Zhongqiu Han @ 2026-03-26 13:16 UTC (permalink / raw)
To: K Prateek Nayak, Rafael J. Wysocki, Viresh Kumar, Huang Rui,
Gautham R. Shenoy, Mario Limonciello, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Srinivas Pandruvada, Len Brown,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Miguel Ojeda
Cc: Perry Yuan, linux-pm, linux-kernel, rust-for-linux,
linux-rt-devel, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Bert Karwatzki, zhongqiu.han
In-Reply-To: <20260316081849.19368-3-kprateek.nayak@amd.com>
On 3/16/2026 4:18 PM, K Prateek Nayak wrote:
> cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent
> writer(s), however amd-pstate depends on fetching the cpudata via the
> policy's driver data which necessitates grabbing the reference.
>
> Since schedutil governor can call "cpufreq_driver->update_perf()"
> during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled,
> fetching the policy object using the cpufreq_cpu_get() helper in the
> scheduler fast-path leads to "BUG: scheduling while atomic" on
> PREEMPT_RT [1].
>
> Pass the cached cpufreq policy object in sg_policy to the update_perf()
> instead of just the CPU. The CPU can be inferred using "policy->cpu".
Agreed, sugov_update_single_perf() is only invoked for CPUs belonging to
a non-shared policy; in this path, policy->cpu is guaranteed to match
sg_cpu->cpu. With that invariant, this patch looks correct to me.
>
> The lifetime of cpufreq_policy object outlasts that of the governor and
> the cpufreq driver (allocated when the CPU is onlined and only reclaimed
> when the CPU is offlined / the CPU device is removed) which makes it
> safe to be referenced throughout the governor's lifetime.
>
> Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State")
> Reported-by: Bert Karwatzki <spasswolf@web.de>
> Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1]
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
> changelog v3..v4:
>
> o Added the Fixes tag. (Gautham, Chris Mason's review-prompts)
> ---
> drivers/cpufreq/amd-pstate.c | 3 +--
> drivers/cpufreq/cpufreq.c | 6 +++---
> drivers/cpufreq/intel_pstate.c | 4 ++--
> include/linux/cpufreq.h | 4 ++--
> kernel/sched/cpufreq_schedutil.c | 5 +++--
> rust/kernel/cpufreq.rs | 13 ++++++-------
> 6 files changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 5faccb3d6b14..ad4b5f84773a 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -710,13 +710,12 @@ static unsigned int amd_pstate_fast_switch(struct cpufreq_policy *policy,
> return policy->cur;
> }
>
> -static void amd_pstate_adjust_perf(unsigned int cpu,
> +static void amd_pstate_adjust_perf(struct cpufreq_policy *policy,
> unsigned long _min_perf,
> unsigned long target_perf,
> unsigned long capacity)
> {
> u8 max_perf, min_perf, des_perf, cap_perf;
> - struct cpufreq_policy *policy __free(put_cpufreq_policy) = cpufreq_cpu_get(cpu);
> struct amd_cpudata *cpudata;
> union perf_cached perf;
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 2082a9e4384f..17a5b8e0ea1e 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2231,7 +2231,7 @@ EXPORT_SYMBOL_GPL(cpufreq_driver_fast_switch);
>
> /**
> * cpufreq_driver_adjust_perf - Adjust CPU performance level in one go.
> - * @cpu: Target CPU.
> + * @policy: cpufreq policy object of the target CPU.
> * @min_perf: Minimum (required) performance level (units of @capacity).
> * @target_perf: Target (desired) performance level (units of @capacity).
> * @capacity: Capacity of the target CPU.
> @@ -2250,12 +2250,12 @@ EXPORT_SYMBOL_GPL(cpufreq_driver_fast_switch);
> * parallel with either ->target() or ->target_index() or ->fast_switch() for
> * the same CPU.
> */
> -void cpufreq_driver_adjust_perf(unsigned int cpu,
> +void cpufreq_driver_adjust_perf(struct cpufreq_policy *policy,
> unsigned long min_perf,
> unsigned long target_perf,
> unsigned long capacity)
> {
> - cpufreq_driver->adjust_perf(cpu, min_perf, target_perf, capacity);
> + cpufreq_driver->adjust_perf(policy, min_perf, target_perf, capacity);
> }
>
> /**
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 51938c5a47ca..1552b2d32a34 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -3239,12 +3239,12 @@ static unsigned int intel_cpufreq_fast_switch(struct cpufreq_policy *policy,
> return target_pstate * cpu->pstate.scaling;
> }
>
> -static void intel_cpufreq_adjust_perf(unsigned int cpunum,
> +static void intel_cpufreq_adjust_perf(struct cpufreq_policy *policy,
> unsigned long min_perf,
> unsigned long target_perf,
> unsigned long capacity)
> {
> - struct cpudata *cpu = all_cpu_data[cpunum];
> + struct cpudata *cpu = all_cpu_data[policy->cpu];
> u64 hwp_cap = READ_ONCE(cpu->hwp_cap_cached);
> int old_pstate = cpu->pstate.current_pstate;
> int cap_pstate, min_pstate, max_pstate, target_pstate;
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index cc894fc38971..4317c5a312bd 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -372,7 +372,7 @@ struct cpufreq_driver {
> * conditions) scale invariance can be disabled, which causes the
> * schedutil governor to fall back to the latter.
> */
> - void (*adjust_perf)(unsigned int cpu,
> + void (*adjust_perf)(struct cpufreq_policy *policy,
> unsigned long min_perf,
> unsigned long target_perf,
> unsigned long capacity);
> @@ -617,7 +617,7 @@ struct cpufreq_governor {
> /* Pass a target to the cpufreq driver */
> unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> unsigned int target_freq);
> -void cpufreq_driver_adjust_perf(unsigned int cpu,
> +void cpufreq_driver_adjust_perf(struct cpufreq_policy *policy,
> unsigned long min_perf,
> unsigned long target_perf,
> unsigned long capacity);
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 153232dd8276..ae9fd211cec1 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -461,6 +461,7 @@ static void sugov_update_single_perf(struct update_util_data *hook, u64 time,
> unsigned int flags)
> {
> struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_util);
> + struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> unsigned long prev_util = sg_cpu->util;
> unsigned long max_cap;
>
> @@ -482,10 +483,10 @@ static void sugov_update_single_perf(struct update_util_data *hook, u64 time,
> if (sugov_hold_freq(sg_cpu) && sg_cpu->util < prev_util)
> sg_cpu->util = prev_util;
>
> - cpufreq_driver_adjust_perf(sg_cpu->cpu, sg_cpu->bw_min,
> + cpufreq_driver_adjust_perf(sg_policy->policy, sg_cpu->bw_min,
> sg_cpu->util, max_cap);
>
> - sg_cpu->sg_policy->last_freq_update_time = time;
> + sg_policy->last_freq_update_time = time;
> }
>
> static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time)
> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
> index 76faa1ac8501..a83aec198336 100644
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -1256,18 +1256,17 @@ impl<T: Driver> Registration<T> {
> /// # Safety
> ///
> /// - This function may only be called from the cpufreq C infrastructure.
> + /// - The pointer arguments must be valid pointers.
> unsafe extern "C" fn adjust_perf_callback(
> - cpu: c_uint,
> + ptr: *mut bindings::cpufreq_policy,
> min_perf: c_ulong,
> target_perf: c_ulong,
> capacity: c_ulong,
> ) {
> - // SAFETY: The C API guarantees that `cpu` refers to a valid CPU number.
> - let cpu_id = unsafe { CpuId::from_u32_unchecked(cpu) };
> -
> - if let Ok(mut policy) = PolicyCpu::from_cpu(cpu_id) {
> - T::adjust_perf(&mut policy, min_perf, target_perf, capacity);
> - }
> + // SAFETY: The `ptr` is guaranteed to be valid by the contract with the C code for the
> + // lifetime of `policy`.
> + let policy = unsafe { Policy::from_raw_mut(ptr) };
> + T::adjust_perf(policy, min_perf, target_perf, capacity);
> }
>
> /// Driver's `get_intermediate` callback.
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Jie Zhan @ 2026-03-26 13:14 UTC (permalink / raw)
To: cw00.choi, myungjoo.ham, kyungmin.park, tianyaxiong
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <20260326123428.800407-1-zhanjie9@hisilicon.com>
On 3/26/2026 8:34 PM, Jie Zhan wrote:
> When compiled as a kernel module, the governor module can be dynamically
> inserted or removed. 'devfreq->governor' would become NULL if the governor
> module is removed when it's in use, and NULL pointer dereference would be
> triggered. A similar issue was also reported in [1].
>
> To address this issue:
>
> Patch 1-5 rework mutex, factor out a common governor setting function, and
> clean up some unreachable code.
>
> Patch 6-8 prevent a governor module in use from being removed (except for
> force unload) by getting/putting a refcount of the governor's module when
> switching governors.
>
> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
> when a governor module in use is force unloaded.
>
> Note that this series is based on [1] or devfreq-next, otherwise code
sorry, based on [2] or devfreq-next
> would conflict.
>
> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH v2] PM: hibernate: call preallocate_image after freeze prepare
From: Mario Limonciello @ 2026-03-26 13:09 UTC (permalink / raw)
To: Matthew Leach, Rafael J. Wysocki, Pavel Machek, Len Brown
Cc: linux-pm, linux-kernel, YoungJun Park, kernel
In-Reply-To: <20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com>
On 3/26/26 06:36, Matthew Leach wrote:
> [You don't often get email from matthew.leach@collabora.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Certain drivers release resources (pinned pages, etc.) into system
> memory during the prepare freeze PM op, making them swappable.
> Currently, hibernate_preallocate_memory is called before prepare freeze,
> so those drivers have no opportunity to release resources first. If a
> driver is holding a large amount of unswappable system RAM, this can
> cause hibernate_preallocate_memory to fail.
>
> Move the call to hibernate_preallocate_memory after prepare freeze.
> According to the documentation for the prepare callback, devices should
> be left in a usable state, so storage drivers should still be able to
> service I/O requests. This allows drivers to release unswappable
> resources prior to preallocation, so they can be swapped out through
> hibernate_preallocate_memory's reclaim path. Also remove
> shrink_shmem_memory since hibernate_preallocate_memory will have
> reclaimed enough memory for the hibernation image.
>
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> Changes in v2:
> - Removed shrink_shmem_memory.
> - Fixed missing call to dpm_prepare in error path.
> - Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
> ---
> kernel/power/hibernate.c | 46 +++++++++-------------------------------------
> 1 file changed, 9 insertions(+), 37 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index af8d07bafe02..39b0a8ea4024 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -392,23 +392,6 @@ static int create_image(int platform_mode)
> return error;
> }
>
> -static void shrink_shmem_memory(void)
> -{
> - struct sysinfo info;
> - unsigned long nr_shmem_pages, nr_freed_pages;
> -
> - si_meminfo(&info);
> - nr_shmem_pages = info.sharedram; /* current page count used for shmem */
> - /*
> - * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
> - * only reclaim about half of them, it's enough for creating the hibernation
> - * image.
> - */
> - nr_freed_pages = shrink_all_memory(nr_shmem_pages);
> - pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
> - nr_shmem_pages, nr_freed_pages);
> -}
> -
> /**
> * hibernation_snapshot - Quiesce devices and create a hibernation image.
> * @platform_mode: If set, use platform driver to prepare for the transition.
> @@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
> if (error)
> goto Close;
>
> - /* Preallocate image memory before shutting down devices. */
> - error = hibernate_preallocate_memory();
> - if (error)
> - goto Close;
> -
> error = freeze_kernel_threads();
> if (error)
> - goto Cleanup;
> + goto Close;
>
> if (hibernation_test(TEST_FREEZER)) {
>
> @@ -441,23 +419,17 @@ int hibernation_snapshot(int platform_mode)
> * successful freezer test.
> */
> freezer_test_done = true;
> - goto Thaw;
> + goto ThawKThreads;
> }
>
> error = dpm_prepare(PMSG_FREEZE);
> - if (error) {
> - dpm_complete(PMSG_RECOVER);
> + if (error)
> goto Thaw;
> - }
>
> - /*
> - * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
> - * pages will use lots of system memory, causing hibernation image creation
> - * fail due to insufficient free memory.
> - * This call is to force flush the shmem pages to swap disk and reclaim
> - * the system memory so that image creation can succeed.
> - */
> - shrink_shmem_memory();
> + /* Preallocate image memory before shutting down devices. */
> + error = hibernate_preallocate_memory();
> + if (error)
> + goto Thaw;
>
> console_suspend_all();
> pm_restrict_gfp_mask();
> @@ -493,9 +465,9 @@ int hibernation_snapshot(int platform_mode)
> return error;
>
> Thaw:
> + dpm_complete(PMSG_RECOVER);
> + ThawKThreads:
> thaw_kernel_threads();
> - Cleanup:
> - swsusp_free();
> goto Close;
> }
>
>
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260321-hibernation-fixes-69bca2ee5b65
>
> Best regards,
> --
> Matt
>
^ permalink raw reply
* Re: [PATCH v7 2/2] cpufreq: Add boost_freq_req QoS request
From: zhenglifeng (A) @ 2026-03-26 13:09 UTC (permalink / raw)
To: Pierre Gondois, linux-kernel
Cc: Huang Rui, Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, Viresh Kumar, linux-pm
In-Reply-To: <20260325165255.386576-3-pierre.gondois@arm.com>
This patch looks good to me now.
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
On 3/26/2026 12:52 AM, Pierre Gondois wrote:
> The Power Management Quality of Service (PM QoS) allows to
> aggregate constraints from multiple entities. It is currently
> used to manage the min/max frequency of a given policy.
>
> Frequency constraints can come for instance from:
> - Thermal framework: acpi_thermal_cpufreq_init()
> - Firmware: _PPC objects: acpi_processor_ppc_init()
> - User: by setting policyX/scaling_[min|max]_freq
> The minimum of the max frequency constraints is used to compute
> the resulting maximum allowed frequency.
>
> When enabling boost frequencies, the same frequency request object
> (policy->max_freq_req) as to handle requests from users is used.
> As a result, when setting:
> - scaling_max_freq
> - boost
> The last sysfs file used overwrites the request from the other
> sysfs file.
>
> To avoid this, create a per-policy boost_freq_req to save the boost
> constraints instead of overwriting the last scaling_max_freq
> constraint.
>
> policy_set_boost() calls the cpufreq set_boost callback.
> Update the newly added boost_freq_req request from there:
> - whenever boost is toggled
> - to cover all possible paths
>
> In the existing .set_boost() callbacks:
> - Don't update policy->max as this is done through the qos notifier
> cpufreq_notifier_max() which calls cpufreq_set_policy().
> - Remove freq_qos_update_request() calls as the qos request is now
> done in policy_set_boost() and updates the new boost_freq_req
>
> $ ## Init state
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
>
> $ echo 700000 > scaling_max_freq
> scaling_max_freq:700000
> cpuinfo_max_freq:1000000
>
> $ echo 1 > ../boost
> scaling_max_freq:1200000
> cpuinfo_max_freq:1200000
>
> $ echo 800000 > scaling_max_freq
> scaling_max_freq:800000
> cpuinfo_max_freq:1200000
>
> $ ## Final step:
> $ ## Without the patches:
> $ echo 0 > ../boost
> scaling_max_freq:1000000
> cpuinfo_max_freq:1000000
>
> $ ## With the patches:
> $ echo 0 > ../boost
> scaling_max_freq:800000
> cpuinfo_max_freq:1000000
>
> Note:
> cpufreq_frequency_table_cpuinfo() updates policy->min
> and max from:
> A.
> cpufreq_boost_set_sw()
> \-cpufreq_frequency_table_cpuinfo()
> B.
> cpufreq_policy_online()
> \-cpufreq_table_validate_and_sort()
> \-cpufreq_frequency_table_cpuinfo()
> Keep these updates as some drivers expect policy->min and
> max to be set through B.
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
> drivers/cpufreq/amd-pstate.c | 2 --
> drivers/cpufreq/cppc_cpufreq.c | 10 ++-----
> drivers/cpufreq/cpufreq.c | 51 ++++++++++++++++++++++++++--------
> include/linux/cpufreq.h | 1 +
> 4 files changed, 43 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 5aa9fcd80cf51..d0675d6a19fe1 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -769,8 +769,6 @@ static int amd_pstate_cpu_boost_update(struct cpufreq_policy *policy, bool on)
> else if (policy->cpuinfo.max_freq > nominal_freq)
> policy->cpuinfo.max_freq = nominal_freq;
>
> - policy->max = policy->cpuinfo.max_freq;
> -
> if (cppc_state == AMD_PSTATE_PASSIVE) {
> ret = freq_qos_update_request(&cpudata->req[1], policy->cpuinfo.max_freq);
> if (ret < 0)
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 011f35cb47b94..f4f574fbe547b 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -807,17 +807,11 @@ static int cppc_cpufreq_set_boost(struct cpufreq_policy *policy, int state)
> {
> struct cppc_cpudata *cpu_data = policy->driver_data;
> struct cppc_perf_caps *caps = &cpu_data->perf_caps;
> - int ret;
>
> if (state)
> - policy->max = cppc_perf_to_khz(caps, caps->highest_perf);
> + policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->highest_perf);
> else
> - policy->max = cppc_perf_to_khz(caps, caps->nominal_perf);
> - policy->cpuinfo.max_freq = policy->max;
> -
> - ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> - if (ret < 0)
> - return ret;
> + policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, caps->nominal_perf);
>
> return 0;
> }
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 5757f12633d16..947ed87cf8d76 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -609,10 +609,19 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
> policy->boost_enabled = enable;
>
> ret = cpufreq_driver->set_boost(policy, enable);
> - if (ret)
> + if (ret) {
> policy->boost_enabled = !policy->boost_enabled;
> + return ret;
> + }
>
> - return ret;
> + ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
> + if (ret < 0) {
> + policy->boost_enabled = !policy->boost_enabled;
> + cpufreq_driver->set_boost(policy, policy->boost_enabled);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static ssize_t store_local_boost(struct cpufreq_policy *policy,
> @@ -1377,6 +1386,8 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> }
>
> freq_qos_remove_request(policy->min_freq_req);
> + if (policy->boost_freq_req)
> + freq_qos_remove_request(policy->boost_freq_req);
> kfree(policy->min_freq_req);
>
> cpufreq_policy_put_kobj(policy);
> @@ -1445,18 +1456,42 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
>
> if (new_policy) {
> + unsigned int req_nr;
> +
> for_each_cpu(j, policy->related_cpus) {
> per_cpu(cpufreq_cpu_data, j) = policy;
> add_cpu_dev_symlink(policy, j, get_cpu_device(j));
> }
>
> - policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req),
> + req_nr = policy->boost_supported ? 3 : 2;
> + policy->min_freq_req = kzalloc(req_nr * sizeof(*policy->min_freq_req),
> GFP_KERNEL);
> if (!policy->min_freq_req) {
> ret = -ENOMEM;
> goto out_destroy_policy;
> }
>
> + if (policy->boost_supported) {
> + policy->boost_freq_req = policy->min_freq_req + 2;
> +
> + /*
> + * If boost is supported,
> + * init the constraint with cpuinfo.max_freq.
> + */
> + ret = freq_qos_add_request(&policy->constraints,
> + policy->boost_freq_req,
> + FREQ_QOS_MAX,
> + policy->cpuinfo.max_freq);
> + if (ret < 0) {
> + /*
> + * So we don't call freq_qos_remove_request() for an
> + * uninitialized request.
> + */
> + policy->boost_freq_req = NULL;
> + goto out_destroy_policy;
> + }
> + }
> +
> ret = freq_qos_add_request(&policy->constraints,
> policy->min_freq_req, FREQ_QOS_MIN,
> FREQ_QOS_MIN_DEFAULT_VALUE);
> @@ -2788,16 +2823,10 @@ int cpufreq_boost_set_sw(struct cpufreq_policy *policy, int state)
> return -ENXIO;
>
> ret = cpufreq_frequency_table_cpuinfo(policy);
> - if (ret) {
> + if (ret)
> pr_err("%s: Policy frequency update failed\n", __func__);
> - return ret;
> - }
> -
> - ret = freq_qos_update_request(policy->max_freq_req, policy->max);
> - if (ret < 0)
> - return ret;
>
> - return 0;
> + return ret;
> }
> EXPORT_SYMBOL_GPL(cpufreq_boost_set_sw);
>
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index cc894fc389710..89157e367eefa 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -81,6 +81,7 @@ struct cpufreq_policy {
> struct freq_constraints constraints;
> struct freq_qos_request *min_freq_req;
> struct freq_qos_request *max_freq_req;
> + struct freq_qos_request *boost_freq_req;
>
> struct cpufreq_frequency_table *freq_table;
> enum cpufreq_table_sorting freq_table_sorted;
^ permalink raw reply
* Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry
From: Vincent Guittot @ 2026-03-26 13:04 UTC (permalink / raw)
To: Christian Loehle
Cc: arighi, peterz, dietmar.eggemann, valentin.schneider, mingo,
rostedt, segall, mgorman, catalin.marinas, will, sudeep.holla,
rafael, linux-pm, linux-kernel, juri.lelli, kobak, fabecassis
In-Reply-To: <7eccf54f-5a99-40ce-8fbc-b755b4e2d312@arm.com>
On Thu, 26 Mar 2026 at 10:24, Christian Loehle <christian.loehle@arm.com> wrote:
>
> On 3/26/26 08:24, Vincent Guittot wrote:
> > On Thu, 26 Mar 2026 at 09:16, Christian Loehle <christian.loehle@arm.com> wrote:
> >>
> >> On 3/26/26 07:53, Vincent Guittot wrote:
> >>> On Wed, 25 Mar 2026 at 19:13, Christian Loehle <christian.loehle@arm.com> wrote:
> >>>>
> >>>> The scheduler currently handles CPU performance asymmetry via either:
> >>>>
> >>>> - SD_ASYM_PACKING: simple priority-based task placement (x86 ITMT)
> >>>> - SD_ASYM_CPUCAPACITY: capacity-aware scheduling
> >>>>
> >>>> On arm64, capacity-aware scheduling is used for any detected capacity
> >>>> differences.
> >>>>
> >>>> Some systems expose small per-CPU performance differences via CPPC
> >>>> highest_perf (e.g. due to chip binning), resulting in slightly different
> >>>> capacities (<~5%). These differences are sufficient to trigger
> >>>> SD_ASYM_CPUCAPACITY, even though the system is otherwise effectively
> >>>> symmetric.
> >>>>
> >>>> For such small deltas, capacity-aware scheduling is unnecessarily
> >>>> complex. A simpler priority-based approach, similar to x86 ITMT, is
> >>>> sufficient.
> >>>
> >>> I'm not convinced that moving to SD_ASYM_PACKING is the right way to
> >>> move forward.
> >>> t
> >>> 1st of all, do you target all kind of system or only SMT? It's not
> >>> clear in your cover letter
> >>
> >> AFAIK only Andrea has access to an unreleased asymmetric SMT system,
> >> I haven't done any tests on such a system (as the cover-letter mentions
> >> under RFT section).
> >>
> >>>
> >>> Moving on asym pack for !SMT doesn't make sense to me. If you don't
> >>> want EAS enabled, you can disable it with
> >>> /proc/sys/kernel/sched_energy_aware
> >>
> >> Sorry, what's EAS got to do with it? The system I care about here
> >> (primarily nvidia grace) has no EM.
> >
> > I tried to understand the end goal of this patch
> >
> > SD_ASYM_CPUCAPACITY works fine with !SMT system so why enabling
> > SD_ASYM_PACKING for <5% diff ?
> >
> > That doesn't make sense to me
> I don't know if "works fine" describes the situation accurately.
> I guess I should've included the context in the cover letter, but you
> are aware of them (you've replied to them anyway):
> https://lore.kernel.org/lkml/20260324005509.1134981-1-arighi@nvidia.com/
> https://lore.kernel.org/lkml/20260318092214.130908-1-arighi@nvidia.com/
>
> Andrea sees an improvement even when force-equalizing CPUs to remove
> SD_ASYM_CPUCAPACITY, so I'd argue it doesn't "work fine" on these platforms.
IIUC this was for SMT systems not for !SMT ones but I might have
missed some emails in the thread.
> To me it seems more reasonable to attempt to get these minor improvements
> of minor asymmetries through asympacking and leave SD_ASYM_CPUCAPACITY
> to the actual 'true' asymmetry (e.g. different uArch or vastly different
> performance levels).
> SD_ASYM_CPUCAPACITY handling is also arguably broken if no CPU pair in
> the system fulfills capacity_greater(), the call sites in fair.c give
> a good overview.
> Is $subject the right approach to deal with these platforms instead?
> I don't know, that's why it's marked RFC and RFT.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox