x86/mce/therm_throt: remove unused platform_thermal_notify function pointer
Subsystems (3)
PATCH 1/3 x86/mce/therm_throt: remove unused platform_thermal_notify function pointer
A long time ago platform_thermal_notify was added as some generic mechanism for platform drivers to hook thermal events. It seems as though this has been entirely superseded, and nothing uses it. Remove the plumbing for this, since this code runs in an interrupt hot path.
--- arch/x86/include/asm/mce.h | 3 --- arch/x86/kernel/cpu/mce/therm_throt.c | 25 ------------------------- 2 files changed, 28 deletions(-)
arch/x86/include/asm/mce.h +0 -3
@@ -257,9 +257,6 @@ extern void (*deferred_error_int_vector)(void);void intel_init_thermal (struct cpuinfo_x86 *c); -/* Interrupt Handler for core thermal thresholds */ -extern int (*platform_thermal_notify)(__u64 msr_val); -/* Interrupt Handler for package thermal thresholds */ extern int (*platform_thermal_package_notify)(__u64 msr_val);
arch/x86/kernel/cpu/mce/therm_throt.c +0 -25
@@ -105,10 +105,6 @@ struct thermal_state {struct _thermal_state pkg_thresh1; }; -/* Callback to handle core threshold interrupts */ -int (*platform_thermal_notify)(__u64 msr_val); -EXPORT_SYMBOL (platform_thermal_notify); -/* Callback to handle core package threshold_interrupts */ int (*platform_thermal_package_notify)(__u64 msr_val);EXPORT_SYMBOL_GPL (platform_thermal_package_notify);
@@ -551,24 +547,6 @@ static void notify_package_thresholds(__u64 msr_val)platform_thermal_package_notify (msr_val); } -static void notify_thresholds (__u64 msr_val) -{ -/* check whether the interrupt handler is defined; -* otherwise simply return -*/ -if (!platform_thermal_notify) -return ; - -/* lower threshold reached */ -if ((msr_val &THERM_LOG_THRESHOLD0 ) && -thresh_event_valid (CORE_LEVEL ,0 )) -platform_thermal_notify (msr_val); -/* higher threshold reached */ -if ((msr_val &THERM_LOG_THRESHOLD1 ) && -thresh_event_valid (CORE_LEVEL ,1 )) -platform_thermal_notify (msr_val); -} -/* Thermal transition interrupt handler */ static void intel_thermal_interrupt (void ) {
@@ -579,9 +557,6 @@ static void intel_thermal_interrupt(void)rdmsrl (MSR_IA32_THERM_STATUS , msr_val); -/* Check for violation of core thermal thresholds*/ -notify_thresholds (msr_val); -therm_throt_process (msr_val &THERM_STATUS_PROCHOT ,THERMAL_THROTTLING_EVENT ,CORE_LEVEL );
Signature · 1 line
2.26.0
PATCH 2/3 x86/mce/therm_throt: allow disabling verbose logging
There is an enormous amount of fiddly book keeping and an auxiliary workqueue just for the purpose of ratelimiting and reliably printing messages regarding thermal events and throttling, which uses CPU in a rather common interrupt. Add an option to disable this verbose reporting.
--- arch/x86/Kconfig | 9 +++++++++ arch/x86/kernel/cpu/mce/therm_throt.c | 3 +++ 2 files changed, 12 insertions(+)
arch/x86/Kconfig +9 -0
@@ -1159,6 +1159,15 @@ config X86_THERMAL_VECTOR def_bool y depends on X86_MCE_INTEL +config X86_MCE_THERMAL_VERBOSE + bool "Verbose logging for thermal events" + depends on X86_THERMAL_VECTOR + ---help--- + Display messages in the kernel log when thermal events are triggered, + such as overheating and throttling. This mostly only uses extra CPU + for ratelimiting and book keeping, so unless you need these logs, it + is safe to say N. + source "arch/x86/events/Kconfig" config X86_LEGACY_VM86
arch/x86/kernel/cpu/mce/therm_throt.c +3 -0
@@ -313,6 +313,9 @@ static void therm_throt_process(bool new_event, int event, int level)u64 now;struct thermal_state *pstate = &per_cpu (thermal_state, this_cpu); +if (!IS_ENABLED (CONFIG_X86_MCE_THERMAL_VERBOSE )) +return ; + now =get_jiffies_64 ();if (level ==CORE_LEVEL ) {if (event ==THERMAL_THROTTLING_EVENT )
Signature · 1 line
2.26.0
PATCH 3/3 x86/mce/therm_throt: allow disabling the thermal vector altogether
In reply to Jason A. DonenfeldThe thermal IRQ handler uses 1.21% CPU on my system when it's hot from compiling things. Indeed looking at /proc/interrupts reveals quite a lot of events coming in. Beyond logging them, the existing drivers on the system don't appear to do very much that I'm interested in. So, add a way to disable this entirely so that I can regain precious CPU cycles.
--- arch/x86/Kconfig | 4 ++++ arch/x86/kernel/cpu/mce/intel.c | 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-)
arch/x86/Kconfig +4 -0
@@ -1157,7 +1157,11 @@ config X86_MCE_INJECT config X86_THERMAL_VECTOR def_bool y + prompt "Machine check thermal vector" depends on X86_MCE_INTEL + ---help--- + Provide support for capturing thermal events, logging them, and + passing them off to other drivers. config X86_MCE_THERMAL_VERBOSE bool "Verbose logging for thermal events"
arch/x86/kernel/cpu/mce/intel.c +2 -1
@@ -511,7 +511,8 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)void mce_intel_feature_init (struct cpuinfo_x86 *c) { -intel_init_thermal (c); +if (IS_ENABLED (CONFIG_X86_THERMAL_VECTOR )) +intel_init_thermal (c);intel_init_cmci ();intel_init_lmce ();intel_ppin_init (c);
Signature · 1 line
2.26.0
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 4 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot from
compiling things. Indeed looking at/proc/interruptsreveals quite a lot
I am curious why you are hitting threshold frequently? What is rdmsr 0x1a2
Quoted 4 lines
of events coming in. Beyond logging them, the existing drivers on the system don't appear to do very much that I'm interested in. So, add a way to disable this entirely so that I can regain precious CPU cycles.
It is showing amount of time system is running in a constrained environment. Lots of real time and HPC folks really care about this.
Thanks,
Srinivas
Quoted 40 lines
Signed-off-by Jason A. Donenfeld <[email protected]>--- arch/x86/Kconfig | 4 ++++ arch/x86/kernel/cpu/mce/intel.c | 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-)arch/x86/Kconfig +3
-0@@ -1157,7 +1157,11 @@ config X86_MCE_INJECT config X86_THERMAL_VECTOR def_bool y + prompt "Machine check thermal vector" depends on X86_MCE_INTEL + ---help--- + Provide support for capturing thermal events, logging them,and
arch/x86/Kconfig +1
-0+ passing them off to other drivers. config X86_MCE_THERMAL_VERBOSE bool "Verbose logging for thermal events"arch/x86/kernel/cpu/mce/intel.c +2
-1@@ -511,7 +511,8 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)void mce_intel_feature_init (struct cpuinfo_x86 *c) { -intel_init_thermal (c); +if (IS_ENABLED (CONFIG_X86_THERMAL_VECTOR )) +intel_init_thermal (c);intel_init_cmci ();intel_init_lmce ();
intel_ppin_init(c);
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 8 lines · Srinivas Pandruvada
Quoted 4 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot from
compiling things. Indeed looking at/proc/interruptsreveals quite a lotI am curious why you are hitting threshold frequently? What is rdmsr
0x1a2
5640000
Quoted 6 lines
Quoted 4 lines
of events coming in. Beyond logging them, the existing drivers on the system don't appear to do very much that I'm interested in. So, add a way to disable this entirely so that I can regain precious CPU cycles.
It is showing amount of time system is running in a constrained environment. Lots of real time and HPC folks really care about this.
Which is why this patch adds an option, not a full removal or something. Real time and HPC people can keep their expensive interrupt. Other people with different varieties of system can disable it.
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 8 lines · Jason A. Donenfeld
Quoted 6 lines · Srinivas Pandruvada
Quoted 5 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot from
compiling things. Indeed looking at/proc/interruptsreveals quite a
lot
Quoted 4 lines
Quoted 2 lines
I am curious why you are hitting threshold frequently? What is rdmsr
0x1a25640000
You are getting too many interrupts at 95C. You should look at your cooling system.
Quoted 11 lines
Quoted 10 lines
Quoted 7 lines
of events coming in. Beyond logging them, the existing drivers on the
system don't appear to do very much that I'm interested in. So, add a
way to disable this entirely so that I can regain precious CPU cycles.It is showing amount of time system is running in a constrained environment. Lots of real time and HPC folks really care about this.
Quoted 5 lines
Which is why this patch adds an option, not a full removal or something. Real time and HPC people can keep their expensive interrupt. Other people with different varieties of system disable
it.
Generally compile time flag is not desirable. If it is what required then we should have boot time flag something in lines of existing "int_pln_enable" option.
Thanks,
Srinivas
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 28 lines · Srinivas Pandruvada
Quoted 8 lines · Jason A. Donenfeld
Quoted 6 lines · Srinivas Pandruvada
Quoted 5 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot from
compiling things. Indeed looking at/proc/interruptsreveals quite a
lotQuoted 4 lines
Quoted 2 lines
I am curious why you are hitting threshold frequently? What is rdmsr
0x1a25640000
You are getting too many interrupts at 95C. You should look at your cooling system.
Quoted 11 lines
Quoted 10 lines
Quoted 7 lines
of events coming in. Beyond logging them, the existing drivers on the
system don't appear to do very much that I'm interested in. So, add a
way to disable this entirely so that I can regain precious CPU cycles.It is showing amount of time system is running in a constrained environment. Lots of real time and HPC folks really care about this.
Quoted 8 lines
Quoted 5 lines
Which is why this patch adds an option, not a full removal or something. Real time and HPC people can keep their expensive interrupt. Other people with different varieties of system disable
it.Generally compile time flag is not desirable. If it is what required then we should have boot time flag something in lines of existing "
int_pln_enable" option.
Generally it is desirable, and extremely common too. This thermal code -- which mostly functions to print some messages into kmsg -- is very verbose. This is not something I want to compile into smaller systems. This is the reason why kconfig has options in the first place. I'm not sure yet-another boottime flag makes sense for this.
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 42 lines · Jason A. Donenfeld
Quoted 35 lines · Srinivas Pandruvada
Quoted 9 lines · Jason A. Donenfeld
Quoted 7 lines · Srinivas Pandruvada
Quoted 6 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot
from
compiling things. Indeed looking at/proc/interruptsreveals quite a
lotQuoted 4 lines
Quoted 2 lines
I am curious why you are hitting threshold frequently? What is rdmsr
0x1a25640000
You are getting too many interrupts at 95C. You should look at your cooling system.
Quoted 13 lines
Quoted 9 lines
Quoted 9 lines
of events coming in. Beyond logging them, the existing drivers on
the
system don't appear to do very much that I'm interested in. So,
add a
way to disable this entirely so that I can regain precious CPU
cycles.Quoted 3 lines
It is showing amount of time system is running in a constrained environment. Lots of real time and HPC folks really care about this.
Quoted 5 lines
Which is why this patch adds an option, not a full removal or something. Real time and HPC people can keep their expensive interrupt. Other people with different varieties of system disable
it.Quoted 4 lines
Generally compile time flag is not desirable. If it is what required
then we should have boot time flag something in lines of existing "int_pln_enable" option.
Quoted 8 lines
Generally it is desirable, and extremely common too. This thermal code
-- which mostly functions to print some messages into kmsg -- is very verbose. This is not something I want to compile into smaller systems.
This is the reason why kconfig has options in the first place. I'm not
sure yet-another boottime flag makes sense for this.
Can you send log which is still showing verbose prints with the latest kernel? I can see interrupts will still fire.
If it is, then temperature trend is still above 95C and cooling systems is not in control. In another window, print in loop (with sleep 1) /sys/class/thermal/thermal_zone*/temp
for the zone for which "type == x86_pkg_temp"
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 53 lines · Srinivas Pandruvada
Quoted 42 lines · Jason A. Donenfeld
Quoted 35 lines · Srinivas Pandruvada
Quoted 9 lines · Jason A. Donenfeld
Quoted 7 lines · Srinivas Pandruvada
Quoted 6 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot
from
compiling things. Indeed looking at/proc/interruptsreveals quite a
lotQuoted 4 lines
Quoted 2 lines
I am curious why you are hitting threshold frequently? What is rdmsr
0x1a25640000
You are getting too many interrupts at 95C. You should look at your cooling system.
Quoted 13 lines
Quoted 9 lines
Quoted 9 lines
of events coming in. Beyond logging them, the existing drivers on
the
system don't appear to do very much that I'm interested in. So,
add a
way to disable this entirely so that I can regain precious CPU
cycles.Quoted 3 lines
It is showing amount of time system is running in a constrained environment. Lots of real time and HPC folks really care about this.
Quoted 5 lines
Which is why this patch adds an option, not a full removal or something. Real time and HPC people can keep their expensive interrupt. Other people with different varieties of system disable
it.Quoted 4 lines
Generally compile time flag is not desirable. If it is what required
then we should have boot time flag something in lines of existing "int_pln_enable" option.Quoted 8 lines
Generally it is desirable, and extremely common too. This thermal code
-- which mostly functions to print some messages into kmsg -- is very verbose. This is not something I want to compile into smaller systems.
This is the reason why kconfig has options in the first place. I'm not
sure yet-another boottime flag makes sense for this.
Quoted 7 lines
Can you send log which is still showing verbose prints with the latest kernel? I can see interrupts will still fire.
If it is, then temperature trend is still above 95C and cooling systems is not in control. In another window, print in loop (with sleep 1)
/sys/class/thermal/thermal_zone*/temp
for the zone for which "type ==x86_pkg_temp"
It sounds like you're interested in debugging the cooling system of my [brand new Thinkpad P1 gen 2] laptop. I appreciate the concern, but that's really not the purpose of this patch. The purpose of this patch is to enable disabling the sizable thermal interrupt code, that does absolutely nothing for a wide variety of systems that do not want that code in their kernel. In other words, I don't think the particular thinkpad cooling aspects have anything to do with the need to add the trivial Kconfig option to not compile this code. I realize it's your code and you might really like it, but that doesn't mean everyone wants it in their kernel image.
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
In reply to Jason A. Donenfeld+ Tony.
Quoted 5 lines · Jason A. Donenfeld
Generally it is desirable, and extremely common too. This thermal code -- which mostly functions to print some messages into kmsg -- is very verbose. This is not something I want to compile into smaller systems. This is the reason why kconfig has options in the first place. I'm not sure yet-another boottime flag makes sense for this.
I don't mind making the already existing option selectable and leaving it default y, i.e., keeping the current situation by default. And people who want to disable it, can then do so.
I do mind to having yet another config option though. No thanks - they're already too many.
So it should be an all or nothing thing.
Poking quickly at that and drivers/thermal/intel/x86_pkg_temp_thermal.c, all those things do is report trip points. therm_throt reports how long the hw throttled due to hitting a trip point, etc.
IINM, of course so please correct me if I'm missing anything.
But if not and this all is only for reporting and doesn't have any detrimental effects on the hardware when missing from the system, then I guess we could make CONFIG_X86_THERMAL_VECTOR user-selectable.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG NürnbergRe: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 30 lines · Borislav Petkov
+ Tony.
Quoted 9 lines · Jason A. Donenfeld
Generally it is desirable, and extremely common too. This thermal code
-- which mostly functions to print some messages into kmsg -- is very
verbose. This is not something I want to compile into smaller systems.
This is the reason why kconfig has options in the first place. I'm not
sure yet-another boottime flag makes sense for this.I don't mind making the already existing option selectable and leaving
it default y, i.e., keeping the current situation by default. And people
who want to disable it, can then do so.I do mind to having yet another config option though. No thanks - they're already too many.
So it should be an all or nothing thing.
Poking quickly at that and
drivers/thermal/intel/x86_pkg_temp_thermal.c,
all those things do is report trip points.therm_throtreports how long
the hw throttled due to hitting a trip point, etc.
Quoted 6 lines
IINM, of course so please correct me if I'm missing anything.
But if not and this all is only for reporting and doesn't have any detrimental effects on the hardware when missing from the system, then I
guess we could makeCONFIG_X86_THERMAL_VECTORuser-selectable.
We can make user selectable
These drivers are used for reporting only.
User space can select a trip temperature via x86_pkg_temp and get notification via uevent to start additional cooling system (additional fans, liquid coooling etc), so that processor don't have to go self throttling mode. Self throttling depending on processor series and firmware can be very aggressive.
In client systems thermald will set a temperature and starts power control once it reaches passive temperature limit. But it can function without x86_pkg_temp also, so even if user disables thermal reporting it can still function.
Thanks,
Srinivas
Quoted 3 lines
Thx.
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 39 lines · Srinivas Pandruvada
Quoted 30 lines · Borislav Petkov
+ Tony.
Quoted 9 lines · Jason A. Donenfeld
Generally it is desirable, and extremely common too. This thermal code
-- which mostly functions to print some messages into kmsg -- is very
verbose. This is not something I want to compile into smaller systems.
This is the reason why kconfig has options in the first place. I'm not
sure yet-another boottime flag makes sense for this.I don't mind making the already existing option selectable and leaving
it default y, i.e., keeping the current situation by default. And people
who want to disable it, can then do so.I do mind to having yet another config option though. No thanks - they're already too many.
So it should be an all or nothing thing.
Poking quickly at that and
drivers/thermal/intel/x86_pkg_temp_thermal.c,
all those things do is report trip points.therm_throtreports how long
the hw throttled due to hitting a trip point, etc.Quoted 6 lines
IINM, of course so please correct me if I'm missing anything.
But if not and this all is only for reporting and doesn't have any detrimental effects on the hardware when missing from the system, then I
guess we could makeCONFIG_X86_THERMAL_VECTORuser-selectable.
Quoted 5 lines
We can make user selectable
These drivers are used for reporting only.
User space can select a trip temperature viax86_pkg_tempand get notification via uevent to start additional cooling system (additional
I didn't see any uevent stuff. Is this part of out-of-tree modules or proprietary code that's hooking into those EXPORT_SYMBOL (non-GPL) exports?
Quoted 7 lines
fans, liquid coooling etc), so that processor don't have to go self throttling mode. Self throttling depending on processor series and firmware can be very aggressive.
In client systems thermald will set a temperature and starts power control once it reaches passive temperature limit. But it can function withoutx86_pkg_tempalso, so even if user disables thermal reporting it can still function.
The 2/3 patch may be interesting as well to you. This removes the expensive work queue management stuff if the option is deselected, since all those workqueues do is print messages to kmsg, while retaining the rest of the infra.
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 48 lines · Jason A. Donenfeld
Quoted 46 lines · Srinivas Pandruvada
Quoted 35 lines · Borislav Petkov
+ Tony.
Quoted 4 lines · Jason A. Donenfeld
Generally it is desirable, and extremely common too. This thermal
code
-- which mostly functions to print some messages into kmsg --Quoted 8 lines
is
very
verbose. This is not something I want to compile into smaller systems.
This is the reason why kconfig has options in the first place. I'm
not
sure yet-another boottime flag makes sense for this.I don't mind making the already existing option selectable and leaving
it default y, i.e., keeping the current situation by default. And people
who want to disable it, can then do so.I do mind to having yet another config option though. No thanks - they're already too many.
So it should be an all or nothing thing.
Poking quickly at that and
drivers/thermal/intel/x86_pkg_temp_thermal.c,
all those things do is report trip points.therm_throtreports how
long
the hw throttled due to hitting a trip point, etc.Quoted 7 lines
IINM, of course so please correct me if I'm missing anything.
But if not and this all is only for reporting and doesn't have any
detrimental effects on the hardware when missing from the system, then I
guess we could makeCONFIG_X86_THERMAL_VECTORuser-selectable.We can make user selectable
Quoted 8 lines
Quoted 4 lines
These drivers are used for reporting only.
User space can select a trip temperature viax86_pkg_tempand get notification via uevent to start additional cooling system (additionalI didn't see any uevent stuff. Is this part of out-of-tree modules or proprietary code that's hooking into those
EXPORT_SYMBOL(non-GPL) exports?
This is not out of tree. This is x86_pkg_temp driver as part of thermal
subsystem, and thermal_zone_device_update() user space governor issues uevent. But those are different modifiable thresholds not the high/low temperature thresholds.
Quoted 15 lines
Quoted 10 lines
fans, liquid coooling etc), so that processor don't have to go self throttling mode. Self throttling depending on processor series and firmware can be very aggressive.
In client systems thermald will set a temperature and starts power control once it reaches passive temperature limit. But it can function
withoutx86_pkg_tempalso, so even if user disables thermal reporting
it can still function.The 2/3 patch may be interesting as well to you. This removes the expensive work queue management stuff if the option is deselected, since all those workqueues do is print messages to kmsg, while retaining the rest of the infra.
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
In reply to Jason A. DonenfeldQuoted 5 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot from compiling things. Indeed looking at
/proc/interruptsreveals quite a lot of events coming in. Beyond logging them, the existing drivers on the system don't appear to do very much that I'm interested in. So, add a way to disable this entirely so that I can regain precious CPU cycles.
Why is this MCE code?!? hysterical raisins?
Anyway, I wonder if this is something we should hook up to SCHED_THERMAL_PRESSURE, Rafael?
Quoted 17 lines
arch/x86/kernel/cpu/mce/intel.c +2
-1@@ -511,7 +511,8 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)void mce_intel_feature_init (struct cpuinfo_x86 *c) { -intel_init_thermal (c); +if (IS_ENABLED (CONFIG_X86_THERMAL_VECTOR )) +intel_init_thermal (c);intel_init_cmci ();intel_init_lmce ();intel_ppin_init (c);Signature · 1 line
2.26.0
Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Quoted 12 lines · Peter Zijlstra
Quoted 10 lines · Jason A. Donenfeld
The thermal IRQ handler uses 1.21% CPU on my system when it's hot from
compiling things. Indeed looking at/proc/interruptsreveals quite a lot
of events coming in. Beyond logging them, the existing drivers on the
system don't appear to do very much that I'm interested in. So, add a
way to disable this entirely so that I can regain precious CPU cycles.
Quoted 1 line
Why is this MCE code?!? hysterical raisins?
When this code was developed long time ago, it was also doing mce logging. But it is no longer doing mce logging, but code is still there.
Quoted 23 lines
Anyway, I wonder if this is something we should hook up to
SCHED_THERMAL_PRESSURE, Rafael?Quoted 19 lines
arch/x86/kernel/cpu/mce/intel.c +2
-1@@ -511,7 +511,8 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)void mce_intel_feature_init (struct cpuinfo_x86 *c) { -intel_init_thermal (c); +if (IS_ENABLED (CONFIG_X86_THERMAL_VECTOR )) +intel_init_thermal (c);intel_init_cmci ();intel_init_lmce ();
intel_ppin_init(c);Signature · 1 line
2.26.0
Hi Srinivas & Co,
Could you have a look at this three part series please? Friendly poke.
Jason
Quoted 4 lines · Jason A. Donenfeld
A long time ago
platform_thermal_notifywas added as some generic mechanism for platform drivers to hook thermal events. It seems as though this has been entirely superseded, and nothing uses it. Remove the plumbing for this, since this code runs in an interrupt hot path.
Good idea.
Thanks,
Srinivas
Quoted 73 lines
Signed-off-by Jason A. Donenfeld <[email protected]>--- arch/x86/include/asm/mce.h | 3 --- arch/x86/kernel/cpu/mce/therm_throt.c | 25 ------------------------- 2 files changed, 28 deletions(-)arch/x86/include/asm/mce.h +0
-3@@ -257,9 +257,6 @@ extern void (*deferred_error_int_vector)(void);void intel_init_thermal (struct cpuinfo_x86 *c); -/* Interrupt Handler for core thermal thresholds */ -extern int (*platform_thermal_notify)(__u64 msr_val); -/* Interrupt Handler for package thermal thresholds */ extern int (*platform_thermal_package_notify)(__u64 msr_val);arch/x86/kernel/cpu/mce/therm_throt.c +0
-22@@ -105,10 +105,6 @@ struct thermal_state {struct _thermal_state pkg_thresh1; }; -/* Callback to handle core threshold interrupts */ -int (*platform_thermal_notify)(__u64 msr_val); -EXPORT_SYMBOL (platform_thermal_notify); -/* Callback to handle core package threshold_interrupts */ int (*platform_thermal_package_notify)(__u64 msr_val);EXPORT_SYMBOL_GPL (platform_thermal_package_notify);@@ -551,24 +547,6 @@ static void notify_package_thresholds(__u64 msr_val)platform_thermal_package_notify (msr_val ); } -static void notify_thresholds (__u64 msr_val) -{ -/* check whether the interrupt handler is defined; -* otherwise simply return -*/ -if (!platform_thermal_notify) -return ; - -/* lower threshold reached */ -if ((msr_val &THERM_LOG_THRESHOLD0 ) && -thresh_event_valid (CORE_LEVEL ,0 )) -platform_thermal_notify (msr_val); -/* higher threshold reached */ -if ((msr_val &THERM_LOG_THRESHOLD1 ) && -thresh_event_valid (CORE_LEVEL ,1 )) -platform_thermal_notify (msr_val); -} -/* Thermal transition interrupt handler */ static void intel_thermal_interrupt (void ){
arch/x86/kernel/cpu/mce/therm_throt.c +0
-3@@ -579,9 +557,6 @@ static void intel_thermal_interrupt(void)rdmsrl (MSR_IA32_THERM_STATUS , msr_val); -/* Check for violation of core thermal thresholds*/ -notify_thresholds (msr_val); -therm_throt_process (msr_val &THERM_STATUS_PROCHOT ,THERMAL_THROTTLING_EVENT ,CORE_LEVEL );
Quoted 7 lines · Srinivas Pandruvada
Quoted 4 lines · Jason A. Donenfeld
A long time ago
platform_thermal_notifywas added as some generic mechanism for platform drivers to hook thermal events. It seems as though this has been entirely superseded, and nothing uses it. Remove the plumbing for this, since this code runs in an interrupt hot path.Good idea.
Will you take this into your tree? If not, how do your thermal patches usually go in? A reviewed-by might be useful in that case.
Jason
Srinivas Pandruvada
Reviewed-byQuoted 10 lines · Jason A. Donenfeld
Quoted 8 lines · Srinivas Pandruvada
Quoted 7 lines · Jason A. Donenfeld
A long time ago
platform_thermal_notifywas added as some generic mechanism for platform drivers to hook thermal events. It seems as
though this has been entirely superseded, and nothing uses it. Remove
the plumbing for this, since this code runs in an interrupt hot path.
Quoted 3 lines
Quoted 1 line
Good idea.
Will you take this into your tree?
I am not the maintainer of this tree. So I don't decide this. I can just give my opinion.
Quoted 2 lines
If not, how do your thermal patches
usually go in? A reviewed-by might be useful in that case.
For this patch:
Quoted 2 lines
Jason