2019-05-19 12:08:55 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2006-09-26 08:52:42 +00:00
|
|
|
/*
|
2006-09-26 08:52:42 +00:00
|
|
|
* Thermal throttle event support code (such as syslog messaging and rate
|
|
|
|
* limiting) that was factored out from x86_64 (mce_intel.c) and i386 (p4.c).
|
2009-04-08 10:31:19 +00:00
|
|
|
*
|
2006-09-26 08:52:42 +00:00
|
|
|
* This allows consistent reporting of CPU thermal throttle events.
|
|
|
|
*
|
|
|
|
* Maintains a counter in /sys that keeps track of the number of thermal
|
|
|
|
* events, such that the user knows how bad the thermal problem might be
|
2017-01-23 18:35:07 +00:00
|
|
|
* (since the logging to syslog is rate limited).
|
2006-09-26 08:52:42 +00:00
|
|
|
*
|
|
|
|
* Author: Dmitriy Zavin (dmitriyz@google.com)
|
|
|
|
*
|
|
|
|
* Credits: Adapted from Zwane Mwaikambo's original code in mce_intel.c.
|
2006-09-26 08:52:42 +00:00
|
|
|
* Inspired by Ross Biro's and Al Borchers' counter code.
|
2006-09-26 08:52:42 +00:00
|
|
|
*/
|
2009-06-15 08:25:27 +00:00
|
|
|
#include <linux/interrupt.h>
|
2009-04-08 10:31:19 +00:00
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/jiffies.h>
|
2009-06-15 08:26:10 +00:00
|
|
|
#include <linux/kernel.h>
|
2006-09-26 08:52:42 +00:00
|
|
|
#include <linux/percpu.h>
|
2011-05-26 16:22:53 +00:00
|
|
|
#include <linux/export.h>
|
2009-06-15 08:26:10 +00:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/smp.h>
|
2006-09-26 08:52:42 +00:00
|
|
|
#include <linux/cpu.h>
|
2009-04-08 10:31:19 +00:00
|
|
|
|
2009-06-15 08:26:10 +00:00
|
|
|
#include <asm/processor.h>
|
2021-01-07 12:29:05 +00:00
|
|
|
#include <asm/thermal.h>
|
2018-11-09 22:13:13 +00:00
|
|
|
#include <asm/traps.h>
|
2009-06-15 08:26:10 +00:00
|
|
|
#include <asm/apic.h>
|
2021-01-07 12:29:05 +00:00
|
|
|
#include <asm/irq.h>
|
2009-06-15 08:26:10 +00:00
|
|
|
#include <asm/msr.h>
|
2006-09-26 08:52:42 +00:00
|
|
|
|
2022-01-27 19:34:50 +00:00
|
|
|
#include "intel_hfi.h"
|
2021-01-07 12:29:05 +00:00
|
|
|
#include "thermal_interrupt.h"
|
2018-12-05 20:05:13 +00:00
|
|
|
|
2006-09-26 08:52:42 +00:00
|
|
|
/* How long to wait between reporting thermal events */
|
2009-04-08 10:31:19 +00:00
|
|
|
#define CHECK_INTERVAL (300 * HZ)
|
2006-09-26 08:52:42 +00:00
|
|
|
|
2010-07-30 00:13:45 +00:00
|
|
|
#define THERMAL_THROTTLING_EVENT 0
|
|
|
|
#define POWER_LIMIT_EVENT 1
|
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
/**
|
|
|
|
* struct _thermal_state - Represent the current thermal event state
|
|
|
|
* @next_check: Stores the next timestamp, when it is allowed
|
|
|
|
* to log the next warning message.
|
|
|
|
* @last_interrupt_time: Stores the timestamp for the last threshold
|
|
|
|
* high event.
|
|
|
|
* @therm_work: Delayed workqueue structure
|
|
|
|
* @count: Stores the current running count for thermal
|
|
|
|
* or power threshold interrupts.
|
|
|
|
* @last_count: Stores the previous running count for thermal
|
|
|
|
* or power threshold interrupts.
|
|
|
|
* @max_time_ms: This shows the maximum amount of time CPU was
|
|
|
|
* in throttled state for a single thermal
|
|
|
|
* threshold high to low state.
|
|
|
|
* @total_time_ms: This is a cumulative time during which CPU was
|
|
|
|
* in the throttled state.
|
|
|
|
* @rate_control_active: Set when a throttling message is logged.
|
|
|
|
* This is used for the purpose of rate-control.
|
|
|
|
* @new_event: Stores the last high/low status of the
|
|
|
|
* THERM_STATUS_PROCHOT or
|
|
|
|
* THERM_STATUS_POWER_LIMIT.
|
|
|
|
* @level: Stores whether this _thermal_state instance is
|
|
|
|
* for a CORE level or for PACKAGE level.
|
|
|
|
* @sample_index: Index for storing the next sample in the buffer
|
|
|
|
* temp_samples[].
|
|
|
|
* @sample_count: Total number of samples collected in the buffer
|
|
|
|
* temp_samples[].
|
|
|
|
* @average: The last moving average of temperature samples
|
|
|
|
* @baseline_temp: Temperature at which thermal threshold high
|
|
|
|
* interrupt was generated.
|
|
|
|
* @temp_samples: Storage for temperature samples to calculate
|
|
|
|
* moving average.
|
|
|
|
*
|
|
|
|
* This structure is used to represent data related to thermal state for a CPU.
|
|
|
|
* There is a separate storage for core and package level for each CPU.
|
2009-09-22 13:50:24 +00:00
|
|
|
*/
|
2010-07-30 00:13:44 +00:00
|
|
|
struct _thermal_state {
|
2009-09-22 13:50:24 +00:00
|
|
|
u64 next_check;
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
u64 last_interrupt_time;
|
|
|
|
struct delayed_work therm_work;
|
2010-07-30 00:13:45 +00:00
|
|
|
unsigned long count;
|
|
|
|
unsigned long last_count;
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
unsigned long max_time_ms;
|
|
|
|
unsigned long total_time_ms;
|
|
|
|
bool rate_control_active;
|
|
|
|
bool new_event;
|
|
|
|
u8 level;
|
|
|
|
u8 sample_index;
|
|
|
|
u8 sample_count;
|
|
|
|
u8 average;
|
|
|
|
u8 baseline_temp;
|
|
|
|
u8 temp_samples[3];
|
2009-09-22 13:50:24 +00:00
|
|
|
};
|
2009-04-08 10:31:19 +00:00
|
|
|
|
2010-07-30 00:13:44 +00:00
|
|
|
struct thermal_state {
|
2010-07-30 00:13:45 +00:00
|
|
|
struct _thermal_state core_throttle;
|
|
|
|
struct _thermal_state core_power_limit;
|
|
|
|
struct _thermal_state package_throttle;
|
|
|
|
struct _thermal_state package_power_limit;
|
2011-01-03 11:52:04 +00:00
|
|
|
struct _thermal_state core_thresh0;
|
|
|
|
struct _thermal_state core_thresh1;
|
2013-05-17 23:42:01 +00:00
|
|
|
struct _thermal_state pkg_thresh0;
|
|
|
|
struct _thermal_state pkg_thresh1;
|
2010-07-30 00:13:44 +00:00
|
|
|
};
|
|
|
|
|
2011-01-03 11:52:04 +00:00
|
|
|
/* Callback to handle core threshold interrupts */
|
|
|
|
int (*platform_thermal_notify)(__u64 msr_val);
|
2011-01-21 04:12:40 +00:00
|
|
|
EXPORT_SYMBOL(platform_thermal_notify);
|
2011-01-03 11:52:04 +00:00
|
|
|
|
2013-05-17 23:42:01 +00:00
|
|
|
/* Callback to handle core package threshold_interrupts */
|
|
|
|
int (*platform_thermal_package_notify)(__u64 msr_val);
|
|
|
|
EXPORT_SYMBOL_GPL(platform_thermal_package_notify);
|
|
|
|
|
|
|
|
/* Callback support of rate control, return true, if
|
|
|
|
* callback has rate control */
|
|
|
|
bool (*platform_thermal_package_rate_control)(void);
|
|
|
|
EXPORT_SYMBOL_GPL(platform_thermal_package_rate_control);
|
|
|
|
|
|
|
|
|
2009-09-22 13:50:24 +00:00
|
|
|
static DEFINE_PER_CPU(struct thermal_state, thermal_state);
|
|
|
|
|
|
|
|
static atomic_t therm_throt_en = ATOMIC_INIT(0);
|
2006-09-26 08:52:42 +00:00
|
|
|
|
2009-11-10 01:38:24 +00:00
|
|
|
static u32 lvtthmr_init __read_mostly;
|
|
|
|
|
2006-09-26 08:52:42 +00:00
|
|
|
#ifdef CONFIG_SYSFS
|
2011-12-21 22:29:42 +00:00
|
|
|
#define define_therm_throt_device_one_ro(_name) \
|
|
|
|
static DEVICE_ATTR(_name, 0444, \
|
|
|
|
therm_throt_device_show_##_name, \
|
2010-07-30 00:13:44 +00:00
|
|
|
NULL) \
|
2009-04-08 10:31:19 +00:00
|
|
|
|
2011-12-21 22:29:42 +00:00
|
|
|
#define define_therm_throt_device_show_func(event, name) \
|
2009-09-22 13:50:24 +00:00
|
|
|
\
|
2011-12-21 22:29:42 +00:00
|
|
|
static ssize_t therm_throt_device_show_##event##_##name( \
|
|
|
|
struct device *dev, \
|
|
|
|
struct device_attribute *attr, \
|
2009-09-22 13:50:24 +00:00
|
|
|
char *buf) \
|
2009-04-08 10:31:19 +00:00
|
|
|
{ \
|
|
|
|
unsigned int cpu = dev->id; \
|
|
|
|
ssize_t ret; \
|
|
|
|
\
|
|
|
|
preempt_disable(); /* CPU hotplug */ \
|
2010-07-30 00:13:44 +00:00
|
|
|
if (cpu_online(cpu)) { \
|
2009-04-08 10:31:19 +00:00
|
|
|
ret = sprintf(buf, "%lu\n", \
|
2010-07-30 00:13:45 +00:00
|
|
|
per_cpu(thermal_state, cpu).event.name); \
|
2010-07-30 00:13:44 +00:00
|
|
|
} else \
|
2009-04-08 10:31:19 +00:00
|
|
|
ret = 0; \
|
|
|
|
preempt_enable(); \
|
|
|
|
\
|
|
|
|
return ret; \
|
2006-09-26 08:52:42 +00:00
|
|
|
}
|
|
|
|
|
2011-12-21 22:29:42 +00:00
|
|
|
define_therm_throt_device_show_func(core_throttle, count);
|
|
|
|
define_therm_throt_device_one_ro(core_throttle_count);
|
2010-07-30 00:13:44 +00:00
|
|
|
|
2011-12-21 22:29:42 +00:00
|
|
|
define_therm_throt_device_show_func(core_power_limit, count);
|
|
|
|
define_therm_throt_device_one_ro(core_power_limit_count);
|
2010-07-30 00:13:45 +00:00
|
|
|
|
2011-12-21 22:29:42 +00:00
|
|
|
define_therm_throt_device_show_func(package_throttle, count);
|
|
|
|
define_therm_throt_device_one_ro(package_throttle_count);
|
2006-09-26 08:52:42 +00:00
|
|
|
|
2011-12-21 22:29:42 +00:00
|
|
|
define_therm_throt_device_show_func(package_power_limit, count);
|
|
|
|
define_therm_throt_device_one_ro(package_power_limit_count);
|
2010-07-30 00:13:45 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
define_therm_throt_device_show_func(core_throttle, max_time_ms);
|
|
|
|
define_therm_throt_device_one_ro(core_throttle_max_time_ms);
|
|
|
|
|
|
|
|
define_therm_throt_device_show_func(package_throttle, max_time_ms);
|
|
|
|
define_therm_throt_device_one_ro(package_throttle_max_time_ms);
|
|
|
|
|
|
|
|
define_therm_throt_device_show_func(core_throttle, total_time_ms);
|
|
|
|
define_therm_throt_device_one_ro(core_throttle_total_time_ms);
|
|
|
|
|
|
|
|
define_therm_throt_device_show_func(package_throttle, total_time_ms);
|
|
|
|
define_therm_throt_device_one_ro(package_throttle_total_time_ms);
|
|
|
|
|
2006-09-26 08:52:42 +00:00
|
|
|
static struct attribute *thermal_throttle_attrs[] = {
|
2011-12-21 22:29:42 +00:00
|
|
|
&dev_attr_core_throttle_count.attr,
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
&dev_attr_core_throttle_max_time_ms.attr,
|
|
|
|
&dev_attr_core_throttle_total_time_ms.attr,
|
2006-09-26 08:52:42 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2017-07-20 11:30:32 +00:00
|
|
|
static const struct attribute_group thermal_attr_group = {
|
2009-04-08 10:31:19 +00:00
|
|
|
.attrs = thermal_throttle_attrs,
|
|
|
|
.name = "thermal_throttle"
|
2006-09-26 08:52:42 +00:00
|
|
|
};
|
|
|
|
#endif /* CONFIG_SYSFS */
|
2006-09-26 08:52:42 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
#define THERM_THROT_POLL_INTERVAL HZ
|
|
|
|
#define THERM_STATUS_PROCHOT_LOG BIT(1)
|
|
|
|
|
2023-04-10 17:35:01 +00:00
|
|
|
static u64 therm_intr_core_clear_mask;
|
|
|
|
static u64 therm_intr_pkg_clear_mask;
|
|
|
|
|
|
|
|
static void thermal_intr_init_core_clear_mask(void)
|
|
|
|
{
|
|
|
|
if (therm_intr_core_clear_mask)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reference: Intel SDM Volume 4
|
|
|
|
* "Table 2-2. IA-32 Architectural MSRs", MSR 0x19C
|
|
|
|
* IA32_THERM_STATUS.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bit 1, 3, 5: CPUID.01H:EDX[22] = 1. This driver will not
|
|
|
|
* enable interrupts, when 0 as it checks for X86_FEATURE_ACPI.
|
|
|
|
*/
|
|
|
|
therm_intr_core_clear_mask = (BIT(1) | BIT(3) | BIT(5));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bit 7 and 9: Thermal Threshold #1 and #2 log
|
|
|
|
* If CPUID.01H:ECX[8] = 1
|
|
|
|
*/
|
|
|
|
if (boot_cpu_has(X86_FEATURE_TM2))
|
|
|
|
therm_intr_core_clear_mask |= (BIT(7) | BIT(9));
|
|
|
|
|
|
|
|
/* Bit 11: Power Limitation log (R/WC0) If CPUID.06H:EAX[4] = 1 */
|
|
|
|
if (boot_cpu_has(X86_FEATURE_PLN))
|
|
|
|
therm_intr_core_clear_mask |= BIT(11);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bit 13: Current Limit log (R/WC0) If CPUID.06H:EAX[7] = 1
|
|
|
|
* Bit 15: Cross Domain Limit log (R/WC0) If CPUID.06H:EAX[7] = 1
|
|
|
|
*/
|
|
|
|
if (boot_cpu_has(X86_FEATURE_HWP))
|
|
|
|
therm_intr_core_clear_mask |= (BIT(13) | BIT(15));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void thermal_intr_init_pkg_clear_mask(void)
|
|
|
|
{
|
|
|
|
if (therm_intr_pkg_clear_mask)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reference: Intel SDM Volume 4
|
|
|
|
* "Table 2-2. IA-32 Architectural MSRs", MSR 0x1B1
|
|
|
|
* IA32_PACKAGE_THERM_STATUS.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* All bits except BIT 26 depend on CPUID.06H: EAX[6] = 1 */
|
|
|
|
if (boot_cpu_has(X86_FEATURE_PTS))
|
|
|
|
therm_intr_pkg_clear_mask = (BIT(1) | BIT(3) | BIT(5) | BIT(7) | BIT(9) | BIT(11));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel SDM Volume 2A: Thermal and Power Management Leaf
|
|
|
|
* Bit 26: CPUID.06H: EAX[19] = 1
|
|
|
|
*/
|
|
|
|
if (boot_cpu_has(X86_FEATURE_HFI))
|
|
|
|
therm_intr_pkg_clear_mask |= BIT(26);
|
|
|
|
}
|
2019-11-28 15:08:24 +00:00
|
|
|
|
2022-11-16 02:54:17 +00:00
|
|
|
/*
|
|
|
|
* Clear the bits in package thermal status register for bit = 1
|
|
|
|
* in bitmask
|
|
|
|
*/
|
|
|
|
void thermal_clear_package_intr_status(int level, u64 bit_mask)
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
{
|
2022-11-16 02:54:17 +00:00
|
|
|
u64 msr_val;
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
int msr;
|
|
|
|
|
2019-11-28 15:08:24 +00:00
|
|
|
if (level == CORE_LEVEL) {
|
|
|
|
msr = MSR_IA32_THERM_STATUS;
|
2023-04-10 17:35:01 +00:00
|
|
|
msr_val = therm_intr_core_clear_mask;
|
2019-11-28 15:08:24 +00:00
|
|
|
} else {
|
|
|
|
msr = MSR_IA32_PACKAGE_THERM_STATUS;
|
2023-04-10 17:35:01 +00:00
|
|
|
msr_val = therm_intr_pkg_clear_mask;
|
2019-11-28 15:08:24 +00:00
|
|
|
}
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
|
2022-11-16 02:54:17 +00:00
|
|
|
msr_val &= ~bit_mask;
|
|
|
|
wrmsrl(msr, msr_val);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
}
|
2022-11-16 02:54:17 +00:00
|
|
|
EXPORT_SYMBOL_GPL(thermal_clear_package_intr_status);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
|
|
|
|
static void get_therm_status(int level, bool *proc_hot, u8 *temp)
|
|
|
|
{
|
|
|
|
int msr;
|
|
|
|
u64 msr_val;
|
|
|
|
|
|
|
|
if (level == CORE_LEVEL)
|
|
|
|
msr = MSR_IA32_THERM_STATUS;
|
|
|
|
else
|
|
|
|
msr = MSR_IA32_PACKAGE_THERM_STATUS;
|
|
|
|
|
|
|
|
rdmsrl(msr, msr_val);
|
|
|
|
if (msr_val & THERM_STATUS_PROCHOT_LOG)
|
|
|
|
*proc_hot = true;
|
|
|
|
else
|
|
|
|
*proc_hot = false;
|
|
|
|
|
|
|
|
*temp = (msr_val >> 16) & 0x7F;
|
|
|
|
}
|
|
|
|
|
2019-12-10 20:39:13 +00:00
|
|
|
static void __maybe_unused throttle_active_work(struct work_struct *work)
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
{
|
|
|
|
struct _thermal_state *state = container_of(to_delayed_work(work),
|
|
|
|
struct _thermal_state, therm_work);
|
|
|
|
unsigned int i, avg, this_cpu = smp_processor_id();
|
|
|
|
u64 now = get_jiffies_64();
|
|
|
|
bool hot;
|
|
|
|
u8 temp;
|
|
|
|
|
|
|
|
get_therm_status(state->level, &hot, &temp);
|
|
|
|
/* temperature value is offset from the max so lesser means hotter */
|
|
|
|
if (!hot && temp > state->baseline_temp) {
|
|
|
|
if (state->rate_control_active)
|
|
|
|
pr_info("CPU%d: %s temperature/speed normal (total events = %lu)\n",
|
|
|
|
this_cpu,
|
|
|
|
state->level == CORE_LEVEL ? "Core" : "Package",
|
|
|
|
state->count);
|
|
|
|
|
|
|
|
state->rate_control_active = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (time_before64(now, state->next_check) &&
|
|
|
|
state->rate_control_active)
|
|
|
|
goto re_arm;
|
|
|
|
|
|
|
|
state->next_check = now + CHECK_INTERVAL;
|
|
|
|
|
|
|
|
if (state->count != state->last_count) {
|
|
|
|
/* There was one new thermal interrupt */
|
|
|
|
state->last_count = state->count;
|
|
|
|
state->average = 0;
|
|
|
|
state->sample_count = 0;
|
|
|
|
state->sample_index = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
state->temp_samples[state->sample_index] = temp;
|
|
|
|
state->sample_count++;
|
|
|
|
state->sample_index = (state->sample_index + 1) % ARRAY_SIZE(state->temp_samples);
|
|
|
|
if (state->sample_count < ARRAY_SIZE(state->temp_samples))
|
|
|
|
goto re_arm;
|
|
|
|
|
|
|
|
avg = 0;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(state->temp_samples); ++i)
|
|
|
|
avg += state->temp_samples[i];
|
|
|
|
|
|
|
|
avg /= ARRAY_SIZE(state->temp_samples);
|
|
|
|
|
|
|
|
if (state->average > avg) {
|
|
|
|
pr_warn("CPU%d: %s temperature is above threshold, cpu clock is throttled (total events = %lu)\n",
|
|
|
|
this_cpu,
|
|
|
|
state->level == CORE_LEVEL ? "Core" : "Package",
|
|
|
|
state->count);
|
|
|
|
state->rate_control_active = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
state->average = avg;
|
|
|
|
|
|
|
|
re_arm:
|
2022-11-16 02:54:17 +00:00
|
|
|
thermal_clear_package_intr_status(state->level, THERM_STATUS_PROCHOT_LOG);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
schedule_delayed_work_on(this_cpu, &state->therm_work, THERM_THROT_POLL_INTERVAL);
|
|
|
|
}
|
|
|
|
|
2006-09-26 08:52:42 +00:00
|
|
|
/***
|
2006-09-26 08:52:42 +00:00
|
|
|
* therm_throt_process - Process thermal throttling event from interrupt
|
2006-09-26 08:52:42 +00:00
|
|
|
* @curr: Whether the condition is current or not (boolean), since the
|
|
|
|
* thermal interrupt normally gets called both when the thermal
|
|
|
|
* event begins and once the event has ended.
|
|
|
|
*
|
2006-09-26 08:52:42 +00:00
|
|
|
* This function is called by the thermal interrupt after the
|
2006-09-26 08:52:42 +00:00
|
|
|
* IRQ has been acknowledged.
|
|
|
|
*
|
|
|
|
* It will take care of rate limiting and printing messages to the syslog.
|
|
|
|
*/
|
2017-01-23 18:35:07 +00:00
|
|
|
static void therm_throt_process(bool new_event, int event, int level)
|
2006-09-26 08:52:42 +00:00
|
|
|
{
|
2010-07-30 00:13:44 +00:00
|
|
|
struct _thermal_state *state;
|
2010-07-30 00:13:45 +00:00
|
|
|
unsigned int this_cpu = smp_processor_id();
|
|
|
|
bool old_event;
|
2009-09-22 13:50:24 +00:00
|
|
|
u64 now;
|
2010-07-30 00:13:45 +00:00
|
|
|
struct thermal_state *pstate = &per_cpu(thermal_state, this_cpu);
|
2009-09-22 13:50:24 +00:00
|
|
|
|
|
|
|
now = get_jiffies_64();
|
2010-07-30 00:13:45 +00:00
|
|
|
if (level == CORE_LEVEL) {
|
|
|
|
if (event == THERMAL_THROTTLING_EVENT)
|
|
|
|
state = &pstate->core_throttle;
|
|
|
|
else if (event == POWER_LIMIT_EVENT)
|
|
|
|
state = &pstate->core_power_limit;
|
|
|
|
else
|
2017-01-23 18:35:07 +00:00
|
|
|
return;
|
2010-07-30 00:13:45 +00:00
|
|
|
} else if (level == PACKAGE_LEVEL) {
|
|
|
|
if (event == THERMAL_THROTTLING_EVENT)
|
|
|
|
state = &pstate->package_throttle;
|
|
|
|
else if (event == POWER_LIMIT_EVENT)
|
|
|
|
state = &pstate->package_power_limit;
|
|
|
|
else
|
2017-01-23 18:35:07 +00:00
|
|
|
return;
|
2010-07-30 00:13:45 +00:00
|
|
|
} else
|
2017-01-23 18:35:07 +00:00
|
|
|
return;
|
2009-09-22 13:50:24 +00:00
|
|
|
|
2010-07-30 00:13:45 +00:00
|
|
|
old_event = state->new_event;
|
|
|
|
state->new_event = new_event;
|
2006-09-26 08:52:42 +00:00
|
|
|
|
2010-07-30 00:13:45 +00:00
|
|
|
if (new_event)
|
|
|
|
state->count++;
|
2006-09-26 08:52:42 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
if (event != THERMAL_THROTTLING_EVENT)
|
2017-01-23 18:35:07 +00:00
|
|
|
return;
|
2006-09-26 08:52:42 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
if (new_event && !state->last_interrupt_time) {
|
|
|
|
bool hot;
|
|
|
|
u8 temp;
|
|
|
|
|
|
|
|
get_therm_status(state->level, &hot, &temp);
|
|
|
|
/*
|
|
|
|
* Ignore short temperature spike as the system is not close
|
|
|
|
* to PROCHOT. 10C offset is large enough to ignore. It is
|
|
|
|
* already dropped from the high threshold temperature.
|
|
|
|
*/
|
|
|
|
if (temp > 10)
|
|
|
|
return;
|
2006-09-26 08:52:42 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
state->baseline_temp = temp;
|
|
|
|
state->last_interrupt_time = now;
|
|
|
|
schedule_delayed_work_on(this_cpu, &state->therm_work, THERM_THROT_POLL_INTERVAL);
|
|
|
|
} else if (old_event && state->last_interrupt_time) {
|
|
|
|
unsigned long throttle_time;
|
|
|
|
|
|
|
|
throttle_time = jiffies_delta_to_msecs(now - state->last_interrupt_time);
|
|
|
|
if (throttle_time > state->max_time_ms)
|
|
|
|
state->max_time_ms = throttle_time;
|
|
|
|
state->total_time_ms += throttle_time;
|
|
|
|
state->last_interrupt_time = 0;
|
2006-09-26 08:52:42 +00:00
|
|
|
}
|
|
|
|
}
|
2006-09-26 08:52:42 +00:00
|
|
|
|
2013-05-17 23:42:01 +00:00
|
|
|
static int thresh_event_valid(int level, int event)
|
2011-01-03 11:52:04 +00:00
|
|
|
{
|
|
|
|
struct _thermal_state *state;
|
|
|
|
unsigned int this_cpu = smp_processor_id();
|
|
|
|
struct thermal_state *pstate = &per_cpu(thermal_state, this_cpu);
|
|
|
|
u64 now = get_jiffies_64();
|
|
|
|
|
2013-05-17 23:42:01 +00:00
|
|
|
if (level == PACKAGE_LEVEL)
|
|
|
|
state = (event == 0) ? &pstate->pkg_thresh0 :
|
|
|
|
&pstate->pkg_thresh1;
|
|
|
|
else
|
|
|
|
state = (event == 0) ? &pstate->core_thresh0 :
|
|
|
|
&pstate->core_thresh1;
|
2011-01-03 11:52:04 +00:00
|
|
|
|
|
|
|
if (time_before64(now, state->next_check))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
state->next_check = now + CHECK_INTERVAL;
|
2013-05-17 23:42:01 +00:00
|
|
|
|
2011-01-03 11:52:04 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-05-21 19:35:17 +00:00
|
|
|
static bool int_pln_enable;
|
|
|
|
static int __init int_pln_enable_setup(char *s)
|
|
|
|
{
|
|
|
|
int_pln_enable = true;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("int_pln_enable", int_pln_enable_setup);
|
|
|
|
|
2006-09-26 08:52:42 +00:00
|
|
|
#ifdef CONFIG_SYSFS
|
2009-04-08 10:31:19 +00:00
|
|
|
/* Add/Remove thermal_throttle interface for CPU device: */
|
x86: delete __cpuinit usage from all x86 files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings. In any case, they are temporary and harmless.
This removes all the arch/x86 uses of the __cpuinit macros from
all C files. x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-06-18 22:23:59 +00:00
|
|
|
static int thermal_throttle_add_dev(struct device *dev, unsigned int cpu)
|
2006-09-26 08:52:42 +00:00
|
|
|
{
|
2010-07-30 00:13:44 +00:00
|
|
|
int err;
|
2010-08-20 07:36:34 +00:00
|
|
|
struct cpuinfo_x86 *c = &cpu_data(cpu);
|
2010-07-30 00:13:44 +00:00
|
|
|
|
2011-12-21 22:29:42 +00:00
|
|
|
err = sysfs_create_group(&dev->kobj, &thermal_attr_group);
|
2010-07-30 00:13:44 +00:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && int_pln_enable) {
|
2011-12-21 22:29:42 +00:00
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_core_power_limit_count.attr,
|
2010-07-30 00:13:45 +00:00
|
|
|
thermal_attr_group.name);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
}
|
|
|
|
|
2010-08-26 08:29:05 +00:00
|
|
|
if (cpu_has(c, X86_FEATURE_PTS)) {
|
2011-12-21 22:29:42 +00:00
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_package_throttle_count.attr,
|
2010-07-30 00:13:45 +00:00
|
|
|
thermal_attr_group.name);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
|
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_package_throttle_max_time_ms.attr,
|
|
|
|
thermal_attr_group.name);
|
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
|
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_package_throttle_total_time_ms.attr,
|
|
|
|
thermal_attr_group.name);
|
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
|
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && int_pln_enable) {
|
2011-12-21 22:29:42 +00:00
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_package_power_limit_count.attr,
|
2010-07-30 00:13:45 +00:00
|
|
|
thermal_attr_group.name);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
}
|
2010-08-26 08:29:05 +00:00
|
|
|
}
|
2010-07-30 00:13:44 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
del_group:
|
|
|
|
sysfs_remove_group(&dev->kobj, &thermal_attr_group);
|
|
|
|
|
2010-07-30 00:13:44 +00:00
|
|
|
return err;
|
2006-09-26 08:52:42 +00:00
|
|
|
}
|
|
|
|
|
x86: delete __cpuinit usage from all x86 files
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.
After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.
Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
are flagged as __cpuinit -- so if we remove the __cpuinit from
arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
content into no-ops as early as possible, since that will get rid
of these warnings. In any case, they are temporary and harmless.
This removes all the arch/x86 uses of the __cpuinit macros from
all C files. x86 only had the one __CPUINIT used in assembly files,
and it wasn't paired off with a .previous or a __FINIT, so we can
delete it directly w/o any corresponding additional change there.
[1] https://lkml.org/lkml/2013/5/20/589
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-06-18 22:23:59 +00:00
|
|
|
static void thermal_throttle_remove_dev(struct device *dev)
|
2006-09-26 08:52:42 +00:00
|
|
|
{
|
2011-12-21 22:29:42 +00:00
|
|
|
sysfs_remove_group(&dev->kobj, &thermal_attr_group);
|
2006-09-26 08:52:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Get notified when a cpu comes on/off. Be hotplug friendly. */
|
2016-11-21 12:15:32 +00:00
|
|
|
static int thermal_throttle_online(unsigned int cpu)
|
2006-09-26 08:52:42 +00:00
|
|
|
{
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
struct thermal_state *state = &per_cpu(thermal_state, cpu);
|
2016-11-17 18:35:22 +00:00
|
|
|
struct device *dev = get_cpu_device(cpu);
|
2020-01-07 00:41:16 +00:00
|
|
|
u32 l;
|
2016-11-17 18:35:22 +00:00
|
|
|
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
state->package_throttle.level = PACKAGE_LEVEL;
|
|
|
|
state->core_throttle.level = CORE_LEVEL;
|
|
|
|
|
|
|
|
INIT_DELAYED_WORK(&state->package_throttle.therm_work, throttle_active_work);
|
|
|
|
INIT_DELAYED_WORK(&state->core_throttle.therm_work, throttle_active_work);
|
|
|
|
|
2022-01-27 19:34:51 +00:00
|
|
|
/*
|
|
|
|
* The first CPU coming online will enable the HFI. Usually this causes
|
|
|
|
* hardware to issue an HFI thermal interrupt. Such interrupt will reach
|
|
|
|
* the CPU once we enable the thermal vector in the local APIC.
|
|
|
|
*/
|
|
|
|
intel_hfi_online(cpu);
|
|
|
|
|
2020-01-07 00:41:16 +00:00
|
|
|
/* Unmask the thermal vector after the above workqueues are initialized. */
|
|
|
|
l = apic_read(APIC_LVTTHMR);
|
|
|
|
apic_write(APIC_LVTTHMR, l & ~APIC_LVT_MASKED);
|
|
|
|
|
2016-11-17 18:35:22 +00:00
|
|
|
return thermal_throttle_add_dev(dev, cpu);
|
2006-09-26 08:52:42 +00:00
|
|
|
}
|
|
|
|
|
2016-11-21 12:15:32 +00:00
|
|
|
static int thermal_throttle_offline(unsigned int cpu)
|
2006-09-26 08:52:42 +00:00
|
|
|
{
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
struct thermal_state *state = &per_cpu(thermal_state, cpu);
|
2016-11-17 18:35:22 +00:00
|
|
|
struct device *dev = get_cpu_device(cpu);
|
2020-02-25 13:55:15 +00:00
|
|
|
u32 l;
|
|
|
|
|
|
|
|
/* Mask the thermal vector before draining evtl. pending work */
|
|
|
|
l = apic_read(APIC_LVTTHMR);
|
|
|
|
apic_write(APIC_LVTTHMR, l | APIC_LVT_MASKED);
|
2016-11-17 18:35:22 +00:00
|
|
|
|
2022-01-27 19:34:51 +00:00
|
|
|
intel_hfi_offline(cpu);
|
|
|
|
|
2020-02-25 13:55:15 +00:00
|
|
|
cancel_delayed_work_sync(&state->package_throttle.therm_work);
|
|
|
|
cancel_delayed_work_sync(&state->core_throttle.therm_work);
|
x86/mce/therm_throt: Optimize notifications of thermal throttle
Some modern systems have very tight thermal tolerances. Because of this
they may cross thermal thresholds when running normal workloads (even
during boot). The CPU hardware will react by limiting power/frequency
and using duty cycles to bring the temperature back into normal range.
Thus users may see a "critical" message about the "temperature above
threshold" which is soon followed by "temperature/speed normal". These
messages are rate-limited, but still may repeat every few minutes.
This issue became worse starting with the Ivy Bridge generation of
CPUs because they include a TCC activation offset in the MSR
IA32_TEMPERATURE_TARGET. OEMs use this to provide alerts long before
critical temperatures are reached.
A test run on a laptop with Intel 8th Gen i5 core for two hours with a
workload resulted in 20K+ thermal interrupts per CPU for core level and
another 20K+ interrupts at package level. The kernel logs were full of
throttling messages.
The real value of these threshold interrupts, is to debug problems with
the external cooling solutions and performance issues due to excessive
throttling.
So the solution here is the following:
- In the current thermal_throttle folder, show:
- the maximum time for one throttling event and,
- the total amount of time the system was in throttling state.
- Do not log short excursions.
- Log only when, in spite of thermal throttling, the temperature is rising.
On the high threshold interrupt trigger a delayed workqueue that
monitors the threshold violation log bit (THERM_STATUS_PROCHOT_LOG). When
the log bit is set, this workqueue callback calculates three point moving
average and logs a warning message when the temperature trend is rising.
When this log bit is clear and temperature is below threshold
temperature, then the workqueue callback logs a "Normal" message. Once a
high threshold event is logged, the logging is rate-limited.
With this patch on the same test laptop, no warnings are printed in the logs
as the max time the processor could bring the temperature under control is
only 280 ms.
This implementation is done with the inputs from Alan Cox and Tony Luck.
[ bp: Touchups. ]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: bberg@redhat.com
Cc: ckellner@redhat.com
Cc: hdegoede@redhat.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191111214312.81365-1-srinivas.pandruvada@linux.intel.com
2019-11-11 21:43:12 +00:00
|
|
|
|
|
|
|
state->package_throttle.rate_control_active = false;
|
|
|
|
state->core_throttle.rate_control_active = false;
|
|
|
|
|
2016-11-17 18:35:22 +00:00
|
|
|
thermal_throttle_remove_dev(dev);
|
|
|
|
return 0;
|
|
|
|
}
|
2006-09-26 08:52:42 +00:00
|
|
|
|
|
|
|
static __init int thermal_throttle_init_device(void)
|
|
|
|
{
|
2016-11-21 12:15:32 +00:00
|
|
|
int ret;
|
2006-09-26 08:52:42 +00:00
|
|
|
|
|
|
|
if (!atomic_read(&therm_throt_en))
|
|
|
|
return 0;
|
|
|
|
|
2022-01-27 19:34:50 +00:00
|
|
|
intel_hfi_init();
|
|
|
|
|
2016-11-21 12:15:32 +00:00
|
|
|
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/therm:online",
|
|
|
|
thermal_throttle_online,
|
|
|
|
thermal_throttle_offline);
|
|
|
|
return ret < 0 ? ret : 0;
|
2006-09-26 08:52:42 +00:00
|
|
|
}
|
|
|
|
device_initcall(thermal_throttle_init_device);
|
2009-06-15 08:25:27 +00:00
|
|
|
|
2006-09-26 08:52:42 +00:00
|
|
|
#endif /* CONFIG_SYSFS */
|
2009-06-15 08:25:27 +00:00
|
|
|
|
2013-05-17 23:42:01 +00:00
|
|
|
static void notify_package_thresholds(__u64 msr_val)
|
|
|
|
{
|
|
|
|
bool notify_thres_0 = false;
|
|
|
|
bool notify_thres_1 = false;
|
|
|
|
|
|
|
|
if (!platform_thermal_package_notify)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* lower threshold check */
|
|
|
|
if (msr_val & THERM_LOG_THRESHOLD0)
|
|
|
|
notify_thres_0 = true;
|
|
|
|
/* higher threshold check */
|
|
|
|
if (msr_val & THERM_LOG_THRESHOLD1)
|
|
|
|
notify_thres_1 = true;
|
|
|
|
|
|
|
|
if (!notify_thres_0 && !notify_thres_1)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (platform_thermal_package_rate_control &&
|
|
|
|
platform_thermal_package_rate_control()) {
|
|
|
|
/* Rate control is implemented in callback */
|
|
|
|
platform_thermal_package_notify(msr_val);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* lower threshold reached */
|
|
|
|
if (notify_thres_0 && thresh_event_valid(PACKAGE_LEVEL, 0))
|
|
|
|
platform_thermal_package_notify(msr_val);
|
|
|
|
/* higher threshold reached */
|
|
|
|
if (notify_thres_1 && thresh_event_valid(PACKAGE_LEVEL, 1))
|
|
|
|
platform_thermal_package_notify(msr_val);
|
|
|
|
}
|
|
|
|
|
2011-01-03 11:52:04 +00:00
|
|
|
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 */
|
2013-05-17 23:42:01 +00:00
|
|
|
if ((msr_val & THERM_LOG_THRESHOLD0) &&
|
|
|
|
thresh_event_valid(CORE_LEVEL, 0))
|
2011-01-03 11:52:04 +00:00
|
|
|
platform_thermal_notify(msr_val);
|
|
|
|
/* higher threshold reached */
|
2013-05-17 23:42:01 +00:00
|
|
|
if ((msr_val & THERM_LOG_THRESHOLD1) &&
|
|
|
|
thresh_event_valid(CORE_LEVEL, 1))
|
2011-01-03 11:52:04 +00:00
|
|
|
platform_thermal_notify(msr_val);
|
|
|
|
}
|
|
|
|
|
2021-08-20 02:40:05 +00:00
|
|
|
void __weak notify_hwp_interrupt(void)
|
|
|
|
{
|
|
|
|
wrmsrl_safe(MSR_HWP_STATUS, 0);
|
|
|
|
}
|
|
|
|
|
2009-06-15 08:25:27 +00:00
|
|
|
/* Thermal transition interrupt handler */
|
2021-01-07 12:29:05 +00:00
|
|
|
void intel_thermal_interrupt(void)
|
2009-06-15 08:25:27 +00:00
|
|
|
{
|
|
|
|
__u64 msr_val;
|
|
|
|
|
2016-03-24 04:07:39 +00:00
|
|
|
if (static_cpu_has(X86_FEATURE_HWP))
|
2021-08-20 02:40:05 +00:00
|
|
|
notify_hwp_interrupt();
|
2016-03-24 04:07:39 +00:00
|
|
|
|
2009-06-15 08:25:27 +00:00
|
|
|
rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
|
2010-07-30 00:13:45 +00:00
|
|
|
|
2011-01-03 11:52:04 +00:00
|
|
|
/* Check for violation of core thermal thresholds*/
|
|
|
|
notify_thresholds(msr_val);
|
|
|
|
|
2017-01-23 18:35:07 +00:00
|
|
|
therm_throt_process(msr_val & THERM_STATUS_PROCHOT,
|
|
|
|
THERMAL_THROTTLING_EVENT,
|
|
|
|
CORE_LEVEL);
|
2010-07-30 00:13:45 +00:00
|
|
|
|
2013-05-21 19:35:17 +00:00
|
|
|
if (this_cpu_has(X86_FEATURE_PLN) && int_pln_enable)
|
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.
Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.
To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.
So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.
This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.
Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Borislav Petkov <bp@amd64.org>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-11-04 20:31:23 +00:00
|
|
|
therm_throt_process(msr_val & THERM_STATUS_POWER_LIMIT,
|
2010-07-30 00:13:45 +00:00
|
|
|
POWER_LIMIT_EVENT,
|
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.
Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.
To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.
So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.
This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.
Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Borislav Petkov <bp@amd64.org>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-11-04 20:31:23 +00:00
|
|
|
CORE_LEVEL);
|
2010-07-30 00:13:44 +00:00
|
|
|
|
2011-03-12 11:50:46 +00:00
|
|
|
if (this_cpu_has(X86_FEATURE_PTS)) {
|
2010-07-30 00:13:44 +00:00
|
|
|
rdmsrl(MSR_IA32_PACKAGE_THERM_STATUS, msr_val);
|
2013-05-17 23:42:01 +00:00
|
|
|
/* check violations of package thermal thresholds */
|
|
|
|
notify_package_thresholds(msr_val);
|
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.
Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.
To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.
So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.
This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.
Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Borislav Petkov <bp@amd64.org>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-11-04 20:31:23 +00:00
|
|
|
therm_throt_process(msr_val & PACKAGE_THERM_STATUS_PROCHOT,
|
2010-07-30 00:13:45 +00:00
|
|
|
THERMAL_THROTTLING_EVENT,
|
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.
Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.
To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.
So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.
This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.
Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Borislav Petkov <bp@amd64.org>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-11-04 20:31:23 +00:00
|
|
|
PACKAGE_LEVEL);
|
2013-05-21 19:35:17 +00:00
|
|
|
if (this_cpu_has(X86_FEATURE_PLN) && int_pln_enable)
|
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.
Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.
To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.
So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.
This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.
Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Borislav Petkov <bp@amd64.org>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-11-04 20:31:23 +00:00
|
|
|
therm_throt_process(msr_val &
|
2010-07-30 00:13:45 +00:00
|
|
|
PACKAGE_THERM_STATUS_POWER_LIMIT,
|
|
|
|
POWER_LIMIT_EVENT,
|
x86, mce, therm_throt: Don't report power limit and package level thermal throttle events in mcelog
Thermal throttle and power limit events are not defined as MCE errors in x86
architecture and should not generate MCE errors in mcelog.
Current kernel generates fake software defined MCE errors for these events.
This may confuse users because they may think the machine has real MCE errors
while actually only thermal throttle or power limit events happen.
To make it worse, buggy firmware on some platforms may falsely generate
the events. Therefore, kernel reports MCE errors which users think as real
hardware errors. Although the firmware bugs should be fixed, on the other hand,
kernel should not report MCE errors either.
So mcelog is not a good mechanism to report these events. To report the events, we count them in respective counters (core_power_limit_count,
package_power_limit_count, core_throttle_count, and package_throttle_count) in
/sys/devices/system/cpu/cpu#/thermal_throttle/. Users can check the counters
for each event on each CPU. Please note that all CPU's on one package report
duplicate counters. It's user application's responsibity to retrieve a package
level counter for one package.
This patch doesn't report package level power limit, core level power limit, and
package level thermal throttle events in mcelog. When the events happen, only
report them in respective counters in sysfs.
Since core level thermal throttle has been legacy code in kernel for a while and
users accepted it as MCE error in mcelog, core level thermal throttle is still
reported in mcelog. In the mean time, the event is counted in a counter in sysfs
as well.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Acked-by: Borislav Petkov <bp@amd64.org>
Acked-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20111215001945.GA21009@linux-os.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2011-11-04 20:31:23 +00:00
|
|
|
PACKAGE_LEVEL);
|
2022-01-27 19:34:52 +00:00
|
|
|
|
|
|
|
if (this_cpu_has(X86_FEATURE_HFI))
|
|
|
|
intel_hfi_process_event(msr_val &
|
|
|
|
PACKAGE_THERM_STATUS_HFI_UPDATED);
|
2010-07-30 00:13:44 +00:00
|
|
|
}
|
2009-06-15 08:25:27 +00:00
|
|
|
}
|
|
|
|
|
2009-12-14 08:57:00 +00:00
|
|
|
/* Thermal monitoring depends on APIC, ACPI and clock modulation */
|
|
|
|
static int intel_thermal_supported(struct cpuinfo_x86 *c)
|
|
|
|
{
|
2016-04-04 20:25:00 +00:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_APIC))
|
2009-12-14 08:57:00 +00:00
|
|
|
return 0;
|
|
|
|
if (!cpu_has(c, X86_FEATURE_ACPI) || !cpu_has(c, X86_FEATURE_ACC))
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2021-01-07 12:29:05 +00:00
|
|
|
bool x86_thermal_enabled(void)
|
|
|
|
{
|
|
|
|
return atomic_read(&therm_throt_en);
|
|
|
|
}
|
|
|
|
|
x86/thermal: Fix LVT thermal setup for SMI delivery mode
There are machines out there with added value crap^WBIOS which provide an
SMI handler for the local APIC thermal sensor interrupt. Out of reset,
the BSP on those machines has something like 0x200 in that APIC register
(timestamps left in because this whole issue is timing sensitive):
[ 0.033858] read lvtthmr: 0x330, val: 0x200
which means:
- bit 16 - the interrupt mask bit is clear and thus that interrupt is enabled
- bits [10:8] have 010b which means SMI delivery mode.
Now, later during boot, when the kernel programs the local APIC, it
soft-disables it temporarily through the spurious vector register:
setup_local_APIC:
...
/*
* If this comes from kexec/kcrash the APIC might be enabled in
* SPIV. Soft disable it before doing further initialization.
*/
value = apic_read(APIC_SPIV);
value &= ~APIC_SPIV_APIC_ENABLED;
apic_write(APIC_SPIV, value);
which means (from the SDM):
"10.4.7.2 Local APIC State After It Has Been Software Disabled
...
* The mask bits for all the LVT entries are set. Attempts to reset these
bits will be ignored."
And this happens too:
[ 0.124111] APIC: Switch to symmetric I/O mode setup
[ 0.124117] lvtthmr 0x200 before write 0xf to APIC 0xf0
[ 0.124118] lvtthmr 0x10200 after write 0xf to APIC 0xf0
This results in CPU 0 soft lockups depending on the placement in time
when the APIC soft-disable happens. Those soft lockups are not 100%
reproducible and the reason for that can only be speculated as no one
tells you what SMM does. Likely, it confuses the SMM code that the APIC
is disabled and the thermal interrupt doesn't doesn't fire at all,
leading to CPU 0 stuck in SMM forever...
Now, before
4f432e8bb15b ("x86/mce: Get rid of mcheck_intel_therm_init()")
due to how the APIC_LVTTHMR was read before APIC initialization in
mcheck_intel_therm_init(), it would read the value with the mask bit 16
clear and then intel_init_thermal() would replicate it onto the APs and
all would be peachy - the thermal interrupt would remain enabled.
But that commit moved that reading to a later moment in
intel_init_thermal(), resulting in reading APIC_LVTTHMR on the BSP too
late and with its interrupt mask bit set.
Thus, revert back to the old behavior of reading the thermal LVT
register before the APIC gets initialized.
Fixes: 4f432e8bb15b ("x86/mce: Get rid of mcheck_intel_therm_init()")
Reported-by: James Feeney <james@nurealm.net>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lkml.kernel.org/r/YKIqDdFNaXYd39wz@zn.tnic
2021-05-27 09:02:26 +00:00
|
|
|
void __init therm_lvt_init(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This function is only called on boot CPU. Save the init thermal
|
|
|
|
* LVT value on BSP and use that value to restore APs' thermal LVT
|
|
|
|
* entry BIOS programmed later
|
|
|
|
*/
|
|
|
|
if (intel_thermal_supported(&boot_cpu_data))
|
|
|
|
lvtthmr_init = apic_read(APIC_LVTTHMR);
|
|
|
|
}
|
|
|
|
|
2009-11-12 06:52:40 +00:00
|
|
|
void intel_init_thermal(struct cpuinfo_x86 *c)
|
2009-06-15 08:26:10 +00:00
|
|
|
{
|
|
|
|
unsigned int cpu = smp_processor_id();
|
|
|
|
int tm2 = 0;
|
|
|
|
u32 l, h;
|
|
|
|
|
2009-12-14 08:57:00 +00:00
|
|
|
if (!intel_thermal_supported(c))
|
2009-06-15 08:26:10 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First check if its enabled already, in which case there might
|
|
|
|
* be some SMM goo which handles it, so we can't even put a handler
|
|
|
|
* since it might be delivered via SMI already:
|
|
|
|
*/
|
|
|
|
rdmsr(MSR_IA32_MISC_ENABLE, l, h);
|
2009-11-10 01:38:24 +00:00
|
|
|
|
2011-04-21 16:22:43 +00:00
|
|
|
h = lvtthmr_init;
|
2009-11-10 01:38:24 +00:00
|
|
|
/*
|
|
|
|
* The initial value of thermal LVT entries on all APs always reads
|
|
|
|
* 0x10000 because APs are woken up by BSP issuing INIT-SIPI-SIPI
|
|
|
|
* sequence to them and LVT registers are reset to 0s except for
|
|
|
|
* the mask bits which are set to 1s when APs receive INIT IPI.
|
2011-04-21 16:22:43 +00:00
|
|
|
* If BIOS takes over the thermal interrupt and sets its interrupt
|
|
|
|
* delivery mode to SMI (not fixed), it restores the value that the
|
|
|
|
* BIOS has programmed on AP based on BSP's info we saved since BIOS
|
|
|
|
* is always setting the same value for all threads/cores.
|
2009-11-10 01:38:24 +00:00
|
|
|
*/
|
2011-04-21 16:22:43 +00:00
|
|
|
if ((h & APIC_DM_FIXED_MASK) != APIC_DM_FIXED)
|
|
|
|
apic_write(APIC_LVTTHMR, lvtthmr_init);
|
2009-11-10 01:38:24 +00:00
|
|
|
|
|
|
|
|
2009-06-15 08:26:10 +00:00
|
|
|
if ((l & MSR_IA32_MISC_ENABLE_TM1) && (h & APIC_DM_SMI)) {
|
2014-09-18 19:22:15 +00:00
|
|
|
if (system_state == SYSTEM_BOOTING)
|
2016-02-02 03:45:02 +00:00
|
|
|
pr_debug("CPU%d: Thermal monitoring handled by SMI\n", cpu);
|
2009-06-15 08:26:10 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-07-28 22:04:59 +00:00
|
|
|
/* early Pentium M models use different method for enabling TM2 */
|
|
|
|
if (cpu_has(c, X86_FEATURE_TM2)) {
|
|
|
|
if (c->x86 == 6 && (c->x86_model == 9 || c->x86_model == 13)) {
|
|
|
|
rdmsr(MSR_THERM2_CTL, l, h);
|
|
|
|
if (l & MSR_THERM2_CTL_TM_SELECT)
|
|
|
|
tm2 = 1;
|
|
|
|
} else if (l & MSR_IA32_MISC_ENABLE_TM2)
|
|
|
|
tm2 = 1;
|
|
|
|
}
|
|
|
|
|
2009-06-15 08:26:10 +00:00
|
|
|
/* We'll mask the thermal vector in the lapic till we're ready: */
|
|
|
|
h = THERMAL_APIC_VECTOR | APIC_DM_FIXED | APIC_LVT_MASKED;
|
|
|
|
apic_write(APIC_LVTTHMR, h);
|
|
|
|
|
2023-04-10 17:35:01 +00:00
|
|
|
thermal_intr_init_core_clear_mask();
|
|
|
|
thermal_intr_init_pkg_clear_mask();
|
|
|
|
|
2009-06-15 08:26:10 +00:00
|
|
|
rdmsr(MSR_IA32_THERM_INTERRUPT, l, h);
|
2013-05-21 19:35:17 +00:00
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable)
|
2010-07-30 00:13:45 +00:00
|
|
|
wrmsr(MSR_IA32_THERM_INTERRUPT,
|
2013-05-21 19:35:17 +00:00
|
|
|
(l | (THERM_INT_LOW_ENABLE
|
|
|
|
| THERM_INT_HIGH_ENABLE)) & ~THERM_INT_PLN_ENABLE, h);
|
|
|
|
else if (cpu_has(c, X86_FEATURE_PLN) && int_pln_enable)
|
2010-07-30 00:13:45 +00:00
|
|
|
wrmsr(MSR_IA32_THERM_INTERRUPT,
|
2013-05-21 19:35:17 +00:00
|
|
|
l | (THERM_INT_LOW_ENABLE
|
2010-07-30 00:13:45 +00:00
|
|
|
| THERM_INT_HIGH_ENABLE | THERM_INT_PLN_ENABLE), h);
|
|
|
|
else
|
|
|
|
wrmsr(MSR_IA32_THERM_INTERRUPT,
|
|
|
|
l | (THERM_INT_LOW_ENABLE | THERM_INT_HIGH_ENABLE), h);
|
2009-06-15 08:26:10 +00:00
|
|
|
|
2010-07-30 00:13:44 +00:00
|
|
|
if (cpu_has(c, X86_FEATURE_PTS)) {
|
|
|
|
rdmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT, l, h);
|
2013-05-21 19:35:17 +00:00
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable)
|
2010-07-30 00:13:45 +00:00
|
|
|
wrmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT,
|
2013-05-21 19:35:17 +00:00
|
|
|
(l | (PACKAGE_THERM_INT_LOW_ENABLE
|
|
|
|
| PACKAGE_THERM_INT_HIGH_ENABLE))
|
|
|
|
& ~PACKAGE_THERM_INT_PLN_ENABLE, h);
|
|
|
|
else if (cpu_has(c, X86_FEATURE_PLN) && int_pln_enable)
|
|
|
|
wrmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT,
|
|
|
|
l | (PACKAGE_THERM_INT_LOW_ENABLE
|
2010-07-30 00:13:45 +00:00
|
|
|
| PACKAGE_THERM_INT_HIGH_ENABLE
|
|
|
|
| PACKAGE_THERM_INT_PLN_ENABLE), h);
|
|
|
|
else
|
|
|
|
wrmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT,
|
|
|
|
l | (PACKAGE_THERM_INT_LOW_ENABLE
|
|
|
|
| PACKAGE_THERM_INT_HIGH_ENABLE), h);
|
2022-01-27 19:34:52 +00:00
|
|
|
|
|
|
|
if (cpu_has(c, X86_FEATURE_HFI)) {
|
|
|
|
rdmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT, l, h);
|
|
|
|
wrmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT,
|
|
|
|
l | PACKAGE_THERM_INT_HFI_ENABLE, h);
|
|
|
|
}
|
2010-07-30 00:13:44 +00:00
|
|
|
}
|
|
|
|
|
2009-06-15 08:26:10 +00:00
|
|
|
rdmsr(MSR_IA32_MISC_ENABLE, l, h);
|
|
|
|
wrmsr(MSR_IA32_MISC_ENABLE, l | MSR_IA32_MISC_ENABLE_TM1, h);
|
|
|
|
|
2016-02-02 03:45:02 +00:00
|
|
|
pr_info_once("CPU0: Thermal monitoring enabled (%s)\n",
|
|
|
|
tm2 ? "TM2" : "TM1");
|
2009-06-15 08:26:10 +00:00
|
|
|
|
|
|
|
/* enable thermal throttle processing */
|
|
|
|
atomic_set(&therm_throt_en, 1);
|
|
|
|
}
|