Re: [PATCH] cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-09-19 10:11:21 [+0200], Uwe Kleine-König wrote:
> notify_hwp_interrupt() is called via sysvec_thermal() ->
> smp_thermal_vector() -> intel_thermal_interrupt() in hard irq context.
> For this reason it must not use a simple spin_lock that sleeps with
> PREEMPT_RT enabled. So convert it to a raw spinlock.
> 
> Reported-by: xiao sheng wen <atzlinux@xxxxxxxx>
> Link: https://bugs.debian.org/1076483
> Signed-off-by: Uwe Kleine-König <ukleinek@xxxxxxxxxx>
> ---
> Hello,
> 
> this is deep in x86 land where I have *very* little experience and
> knowledge. Is sysvec_thermal() (defined in arch/x86/kernel/irq.c) really
> running in hard irq context? The stacktrace in the Debian bug report
> suggests that.
> 
> So please double check my reasoning before applying this patch.

Yes, these things are not threaded. Ideally you should have proper
thermal setup so that you don't get any interrupts in regard to this and
start throttling. Once that interrupt fires and starts throttling then
your worst-case latency increases due to the interrupt and lower CPU
frequency.
Delaying the thermal interrupt to a thread might not be wise.

Acked-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>

> Thanks
> Uwe

Sebastian





[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux