2019-05-19 13:08:55 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2006-09-26 10:52:42 +02:00
|
|
|
/*
|
2006-09-26 10:52:42 +02: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 12:31:19 +02:00
|
|
|
*
|
2006-09-26 10:52:42 +02: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 19:35:07 +01:00
|
|
|
* (since the logging to syslog is rate limited).
|
2006-09-26 10:52:42 +02:00
|
|
|
*
|
|
|
|
* Author: Dmitriy Zavin (dmitriyz@google.com)
|
|
|
|
*
|
|
|
|
* Credits: Adapted from Zwane Mwaikambo's original code in mce_intel.c.
|
2006-09-26 10:52:42 +02:00
|
|
|
* Inspired by Ross Biro's and Al Borchers' counter code.
|
2006-09-26 10:52:42 +02:00
|
|
|
*/
|
2009-06-15 17:25:27 +09:00
|
|
|
#include <linux/interrupt.h>
|
2009-04-08 12:31:19 +02:00
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/jiffies.h>
|
2009-06-15 17:26:10 +09:00
|
|
|
#include <linux/kernel.h>
|
2006-09-26 10:52:42 +02:00
|
|
|
#include <linux/percpu.h>
|
2011-05-26 12:22:53 -04:00
|
|
|
#include <linux/export.h>
|
2009-06-15 17:26:10 +09:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/smp.h>
|
2006-09-26 10:52:42 +02:00
|
|
|
#include <linux/cpu.h>
|
2009-04-08 12:31:19 +02:00
|
|
|
|
2009-06-15 17:26:10 +09:00
|
|
|
#include <asm/processor.h>
|
2018-11-09 23:13:13 +01:00
|
|
|
#include <asm/traps.h>
|
2009-06-15 17:26:10 +09:00
|
|
|
#include <asm/apic.h>
|
2009-06-15 17:25:27 +09:00
|
|
|
#include <asm/mce.h>
|
2009-06-15 17:26:10 +09:00
|
|
|
#include <asm/msr.h>
|
x86, trace: Add irq vector tracepoints
[Purpose of this patch]
As Vaibhav explained in the thread below, tracepoints for irq vectors
are useful.
http://www.spinics.net/lists/mm-commits/msg85707.html
<snip>
The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled. They provide good data about when
the system has switched to kernel space and how it affects the currently
running processes.
There are some IRQ vectors which trigger the system into kernel space,
which are not handled in generic IRQ handlers. Tracing such events gives
us the information about IRQ interaction with other system events.
The trace also tells where the system is spending its time. We want to
know which cores are handling interrupts and how they are affecting other
processes in the system. Also, the trace provides information about when
the cores are idle and which interrupts are changing that state.
<snip>
On the other hand, my usecase is tracing just local timer event and
getting a value of instruction pointer.
I suggested to add an argument local timer event to get instruction pointer before.
But there is another way to get it with external module like systemtap.
So, I don't need to add any argument to irq vector tracepoints now.
[Patch Description]
Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
But there is an above use case to trace specific irq_vector rather than tracing all events.
In this case, we are concerned about overhead due to unwanted events.
So, add following tracepoints instead of introducing irq_vector_entry/exit.
so that we can enable them independently.
- local_timer_vector
- reschedule_vector
- call_function_vector
- call_function_single_vector
- irq_work_entry_vector
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
makes a zero when tracepoints are disabled. Detailed explanations are as follows.
- Create trace irq handlers with entering_irq()/exiting_irq().
- Create a new IDT, trace_idt_table, at boot time by adding a logic to
_set_gate(). It is just a copy of original idt table.
- Register the new handlers for tracpoints to the new IDT by introducing
macros to alloc_intr_gate() called at registering time of irq_vector handlers.
- Add checking, whether irq vector tracing is on/off, into load_current_idt().
This has to be done below debug checking for these reasons.
- Switching to debug IDT may be kicked while tracing is enabled.
- On the other hands, switching to trace IDT is kicked only when debugging
is disabled.
In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
used for other purposes.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
2013-06-20 11:46:53 -04:00
|
|
|
#include <asm/trace/irq_vectors.h>
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2018-12-05 21:05:13 +01:00
|
|
|
#include "internal.h"
|
|
|
|
|
2006-09-26 10:52:42 +02:00
|
|
|
/* How long to wait between reporting thermal events */
|
2009-04-08 12:31:19 +02:00
|
|
|
#define CHECK_INTERVAL (300 * HZ)
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2010-07-29 17:13:45 -07: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 13:43:12 -08: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 15:50:24 +02:00
|
|
|
*/
|
2010-07-29 17:13:44 -07:00
|
|
|
struct _thermal_state {
|
2009-09-22 15:50:24 +02: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 13:43:12 -08:00
|
|
|
u64 last_interrupt_time;
|
|
|
|
struct delayed_work therm_work;
|
2010-07-29 17:13:45 -07: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 13:43:12 -08: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 15:50:24 +02:00
|
|
|
};
|
2009-04-08 12:31:19 +02:00
|
|
|
|
2010-07-29 17:13:44 -07:00
|
|
|
struct thermal_state {
|
2010-07-29 17:13:45 -07: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 17:22:04 +05:30
|
|
|
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-29 17:13:44 -07:00
|
|
|
};
|
|
|
|
|
2011-01-03 17:22:04 +05:30
|
|
|
/* Callback to handle core threshold interrupts */
|
|
|
|
int (*platform_thermal_notify)(__u64 msr_val);
|
2011-01-20 20:12:40 -08:00
|
|
|
EXPORT_SYMBOL(platform_thermal_notify);
|
2011-01-03 17:22:04 +05:30
|
|
|
|
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 15:50:24 +02:00
|
|
|
static DEFINE_PER_CPU(struct thermal_state, thermal_state);
|
|
|
|
|
|
|
|
static atomic_t therm_throt_en = ATOMIC_INIT(0);
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2009-11-10 09:38:24 +08:00
|
|
|
static u32 lvtthmr_init __read_mostly;
|
|
|
|
|
2006-09-26 10:52:42 +02:00
|
|
|
#ifdef CONFIG_SYSFS
|
2011-12-21 14:29:42 -08:00
|
|
|
#define define_therm_throt_device_one_ro(_name) \
|
|
|
|
static DEVICE_ATTR(_name, 0444, \
|
|
|
|
therm_throt_device_show_##_name, \
|
2010-07-29 17:13:44 -07:00
|
|
|
NULL) \
|
2009-04-08 12:31:19 +02:00
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
#define define_therm_throt_device_show_func(event, name) \
|
2009-09-22 15:50:24 +02:00
|
|
|
\
|
2011-12-21 14:29:42 -08:00
|
|
|
static ssize_t therm_throt_device_show_##event##_##name( \
|
|
|
|
struct device *dev, \
|
|
|
|
struct device_attribute *attr, \
|
2009-09-22 15:50:24 +02:00
|
|
|
char *buf) \
|
2009-04-08 12:31:19 +02:00
|
|
|
{ \
|
|
|
|
unsigned int cpu = dev->id; \
|
|
|
|
ssize_t ret; \
|
|
|
|
\
|
|
|
|
preempt_disable(); /* CPU hotplug */ \
|
2010-07-29 17:13:44 -07:00
|
|
|
if (cpu_online(cpu)) { \
|
2009-04-08 12:31:19 +02:00
|
|
|
ret = sprintf(buf, "%lu\n", \
|
2010-07-29 17:13:45 -07:00
|
|
|
per_cpu(thermal_state, cpu).event.name); \
|
2010-07-29 17:13:44 -07:00
|
|
|
} else \
|
2009-04-08 12:31:19 +02:00
|
|
|
ret = 0; \
|
|
|
|
preempt_enable(); \
|
|
|
|
\
|
|
|
|
return ret; \
|
2006-09-26 10:52:42 +02:00
|
|
|
}
|
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
define_therm_throt_device_show_func(core_throttle, count);
|
|
|
|
define_therm_throt_device_one_ro(core_throttle_count);
|
2010-07-29 17:13:44 -07:00
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
define_therm_throt_device_show_func(core_power_limit, count);
|
|
|
|
define_therm_throt_device_one_ro(core_power_limit_count);
|
2010-07-29 17:13:45 -07:00
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
define_therm_throt_device_show_func(package_throttle, count);
|
|
|
|
define_therm_throt_device_one_ro(package_throttle_count);
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
define_therm_throt_device_show_func(package_power_limit, count);
|
|
|
|
define_therm_throt_device_one_ro(package_power_limit_count);
|
2010-07-29 17:13:45 -07: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 13:43:12 -08: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 10:52:42 +02:00
|
|
|
static struct attribute *thermal_throttle_attrs[] = {
|
2011-12-21 14:29:42 -08: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 13:43:12 -08:00
|
|
|
&dev_attr_core_throttle_max_time_ms.attr,
|
|
|
|
&dev_attr_core_throttle_total_time_ms.attr,
|
2006-09-26 10:52:42 +02:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2017-07-20 17:00:32 +05:30
|
|
|
static const struct attribute_group thermal_attr_group = {
|
2009-04-08 12:31:19 +02:00
|
|
|
.attrs = thermal_throttle_attrs,
|
|
|
|
.name = "thermal_throttle"
|
2006-09-26 10:52:42 +02:00
|
|
|
};
|
|
|
|
#endif /* CONFIG_SYSFS */
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2010-07-29 17:13:45 -07:00
|
|
|
#define CORE_LEVEL 0
|
|
|
|
#define PACKAGE_LEVEL 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 13:43:12 -08:00
|
|
|
#define THERM_THROT_POLL_INTERVAL HZ
|
|
|
|
#define THERM_STATUS_PROCHOT_LOG BIT(1)
|
|
|
|
|
2019-11-28 07:08:24 -08:00
|
|
|
#define THERM_STATUS_CLEAR_CORE_MASK (BIT(1) | BIT(3) | BIT(5) | BIT(7) | BIT(9) | BIT(11) | BIT(13) | BIT(15))
|
|
|
|
#define THERM_STATUS_CLEAR_PKG_MASK (BIT(1) | BIT(3) | BIT(5) | BIT(7) | BIT(9) | BIT(11))
|
|
|
|
|
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 13:43:12 -08:00
|
|
|
static void clear_therm_status_log(int level)
|
|
|
|
{
|
|
|
|
int msr;
|
2019-11-28 07:08:24 -08:00
|
|
|
u64 mask, 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 13:43:12 -08:00
|
|
|
|
2019-11-28 07:08:24 -08:00
|
|
|
if (level == CORE_LEVEL) {
|
|
|
|
msr = MSR_IA32_THERM_STATUS;
|
|
|
|
mask = THERM_STATUS_CLEAR_CORE_MASK;
|
|
|
|
} else {
|
|
|
|
msr = MSR_IA32_PACKAGE_THERM_STATUS;
|
|
|
|
mask = THERM_STATUS_CLEAR_PKG_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 13:43:12 -08:00
|
|
|
|
|
|
|
rdmsrl(msr, msr_val);
|
2019-11-28 07:08:24 -08:00
|
|
|
msr_val &= 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 13:43:12 -08:00
|
|
|
wrmsrl(msr, msr_val & ~THERM_STATUS_PROCHOT_LOG);
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void throttle_active_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
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:
|
|
|
|
clear_therm_status_log(state->level);
|
|
|
|
schedule_delayed_work_on(this_cpu, &state->therm_work, THERM_THROT_POLL_INTERVAL);
|
|
|
|
}
|
|
|
|
|
2006-09-26 10:52:42 +02:00
|
|
|
/***
|
2006-09-26 10:52:42 +02:00
|
|
|
* therm_throt_process - Process thermal throttling event from interrupt
|
2006-09-26 10:52:42 +02: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 10:52:42 +02:00
|
|
|
* This function is called by the thermal interrupt after the
|
2006-09-26 10:52:42 +02:00
|
|
|
* IRQ has been acknowledged.
|
|
|
|
*
|
|
|
|
* It will take care of rate limiting and printing messages to the syslog.
|
|
|
|
*/
|
2017-01-23 19:35:07 +01:00
|
|
|
static void therm_throt_process(bool new_event, int event, int level)
|
2006-09-26 10:52:42 +02:00
|
|
|
{
|
2010-07-29 17:13:44 -07:00
|
|
|
struct _thermal_state *state;
|
2010-07-29 17:13:45 -07:00
|
|
|
unsigned int this_cpu = smp_processor_id();
|
|
|
|
bool old_event;
|
2009-09-22 15:50:24 +02:00
|
|
|
u64 now;
|
2010-07-29 17:13:45 -07:00
|
|
|
struct thermal_state *pstate = &per_cpu(thermal_state, this_cpu);
|
2009-09-22 15:50:24 +02:00
|
|
|
|
|
|
|
now = get_jiffies_64();
|
2010-07-29 17:13:45 -07: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 19:35:07 +01:00
|
|
|
return;
|
2010-07-29 17:13:45 -07: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 19:35:07 +01:00
|
|
|
return;
|
2010-07-29 17:13:45 -07:00
|
|
|
} else
|
2017-01-23 19:35:07 +01:00
|
|
|
return;
|
2009-09-22 15:50:24 +02:00
|
|
|
|
2010-07-29 17:13:45 -07:00
|
|
|
old_event = state->new_event;
|
|
|
|
state->new_event = new_event;
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2010-07-29 17:13:45 -07:00
|
|
|
if (new_event)
|
|
|
|
state->count++;
|
2006-09-26 10:52:42 +02: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 13:43:12 -08:00
|
|
|
if (event != THERMAL_THROTTLING_EVENT)
|
2017-01-23 19:35:07 +01:00
|
|
|
return;
|
2006-09-26 10:52:42 +02: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 13:43:12 -08: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 10:52:42 +02: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 13:43:12 -08: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 10:52:42 +02:00
|
|
|
}
|
|
|
|
}
|
2006-09-26 10:52:42 +02:00
|
|
|
|
2013-05-17 23:42:01 +00:00
|
|
|
static int thresh_event_valid(int level, int event)
|
2011-01-03 17:22:04 +05:30
|
|
|
{
|
|
|
|
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 17:22:04 +05:30
|
|
|
|
|
|
|
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 17:22:04 +05:30
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-05-21 15:35:17 -04: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 10:52:42 +02:00
|
|
|
#ifdef CONFIG_SYSFS
|
2009-04-08 12:31:19 +02: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 18:23:59 -04:00
|
|
|
static int thermal_throttle_add_dev(struct device *dev, unsigned int cpu)
|
2006-09-26 10:52:42 +02:00
|
|
|
{
|
2010-07-29 17:13:44 -07:00
|
|
|
int err;
|
2010-08-20 10:36:34 +03:00
|
|
|
struct cpuinfo_x86 *c = &cpu_data(cpu);
|
2010-07-29 17:13:44 -07:00
|
|
|
|
2011-12-21 14:29:42 -08:00
|
|
|
err = sysfs_create_group(&dev->kobj, &thermal_attr_group);
|
2010-07-29 17:13:44 -07: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 13:43:12 -08:00
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && int_pln_enable) {
|
2011-12-21 14:29:42 -08:00
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_core_power_limit_count.attr,
|
2010-07-29 17:13:45 -07: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 13:43:12 -08:00
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
}
|
|
|
|
|
2010-08-26 17:29:05 +09:00
|
|
|
if (cpu_has(c, X86_FEATURE_PTS)) {
|
2011-12-21 14:29:42 -08:00
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_package_throttle_count.attr,
|
2010-07-29 17:13:45 -07: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 13:43:12 -08: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 14:29:42 -08:00
|
|
|
err = sysfs_add_file_to_group(&dev->kobj,
|
|
|
|
&dev_attr_package_power_limit_count.attr,
|
2010-07-29 17:13:45 -07: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 13:43:12 -08:00
|
|
|
if (err)
|
|
|
|
goto del_group;
|
|
|
|
}
|
2010-08-26 17:29:05 +09:00
|
|
|
}
|
2010-07-29 17:13:44 -07: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 13:43:12 -08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
del_group:
|
|
|
|
sysfs_remove_group(&dev->kobj, &thermal_attr_group);
|
|
|
|
|
2010-07-29 17:13:44 -07:00
|
|
|
return err;
|
2006-09-26 10:52:42 +02: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 18:23:59 -04:00
|
|
|
static void thermal_throttle_remove_dev(struct device *dev)
|
2006-09-26 10:52:42 +02:00
|
|
|
{
|
2011-12-21 14:29:42 -08:00
|
|
|
sysfs_remove_group(&dev->kobj, &thermal_attr_group);
|
2006-09-26 10:52:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Get notified when a cpu comes on/off. Be hotplug friendly. */
|
2016-11-21 13:15:32 +01:00
|
|
|
static int thermal_throttle_online(unsigned int cpu)
|
2006-09-26 10:52:42 +02: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 13:43:12 -08:00
|
|
|
struct thermal_state *state = &per_cpu(thermal_state, cpu);
|
2016-11-17 19:35:22 +01:00
|
|
|
struct device *dev = get_cpu_device(cpu);
|
|
|
|
|
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 13:43:12 -08: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);
|
|
|
|
|
2016-11-17 19:35:22 +01:00
|
|
|
return thermal_throttle_add_dev(dev, cpu);
|
2006-09-26 10:52:42 +02:00
|
|
|
}
|
|
|
|
|
2016-11-21 13:15:32 +01:00
|
|
|
static int thermal_throttle_offline(unsigned int cpu)
|
2006-09-26 10:52:42 +02: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 13:43:12 -08:00
|
|
|
struct thermal_state *state = &per_cpu(thermal_state, cpu);
|
2016-11-17 19:35:22 +01:00
|
|
|
struct device *dev = get_cpu_device(cpu);
|
|
|
|
|
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 13:43:12 -08:00
|
|
|
cancel_delayed_work(&state->package_throttle.therm_work);
|
|
|
|
cancel_delayed_work(&state->core_throttle.therm_work);
|
|
|
|
|
|
|
|
state->package_throttle.rate_control_active = false;
|
|
|
|
state->core_throttle.rate_control_active = false;
|
|
|
|
|
2016-11-17 19:35:22 +01:00
|
|
|
thermal_throttle_remove_dev(dev);
|
|
|
|
return 0;
|
|
|
|
}
|
2006-09-26 10:52:42 +02:00
|
|
|
|
|
|
|
static __init int thermal_throttle_init_device(void)
|
|
|
|
{
|
2016-11-21 13:15:32 +01:00
|
|
|
int ret;
|
2006-09-26 10:52:42 +02:00
|
|
|
|
|
|
|
if (!atomic_read(&therm_throt_en))
|
|
|
|
return 0;
|
|
|
|
|
2016-11-21 13:15:32 +01: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 10:52:42 +02:00
|
|
|
}
|
|
|
|
device_initcall(thermal_throttle_init_device);
|
2009-06-15 17:25:27 +09:00
|
|
|
|
2006-09-26 10:52:42 +02:00
|
|
|
#endif /* CONFIG_SYSFS */
|
2009-06-15 17:25:27 +09: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 17:22:04 +05:30
|
|
|
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 17:22:04 +05:30
|
|
|
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 17:22:04 +05:30
|
|
|
platform_thermal_notify(msr_val);
|
|
|
|
}
|
|
|
|
|
2009-06-15 17:25:27 +09:00
|
|
|
/* Thermal transition interrupt handler */
|
2009-06-15 17:26:36 +09:00
|
|
|
static void intel_thermal_interrupt(void)
|
2009-06-15 17:25:27 +09:00
|
|
|
{
|
|
|
|
__u64 msr_val;
|
|
|
|
|
2016-03-23 21:07:39 -07:00
|
|
|
if (static_cpu_has(X86_FEATURE_HWP))
|
|
|
|
wrmsrl_safe(MSR_HWP_STATUS, 0);
|
|
|
|
|
2009-06-15 17:25:27 +09:00
|
|
|
rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
|
2010-07-29 17:13:45 -07:00
|
|
|
|
2011-01-03 17:22:04 +05:30
|
|
|
/* Check for violation of core thermal thresholds*/
|
|
|
|
notify_thresholds(msr_val);
|
|
|
|
|
2017-01-23 19:35:07 +01:00
|
|
|
therm_throt_process(msr_val & THERM_STATUS_PROCHOT,
|
|
|
|
THERMAL_THROTTLING_EVENT,
|
|
|
|
CORE_LEVEL);
|
2010-07-29 17:13:45 -07:00
|
|
|
|
2013-05-21 15:35:17 -04: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 13:31:23 -07:00
|
|
|
therm_throt_process(msr_val & THERM_STATUS_POWER_LIMIT,
|
2010-07-29 17:13:45 -07: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 13:31:23 -07:00
|
|
|
CORE_LEVEL);
|
2010-07-29 17:13:44 -07:00
|
|
|
|
2011-03-12 12:50:46 +01:00
|
|
|
if (this_cpu_has(X86_FEATURE_PTS)) {
|
2010-07-29 17:13:44 -07: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 13:31:23 -07:00
|
|
|
therm_throt_process(msr_val & PACKAGE_THERM_STATUS_PROCHOT,
|
2010-07-29 17:13:45 -07: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 13:31:23 -07:00
|
|
|
PACKAGE_LEVEL);
|
2013-05-21 15:35:17 -04: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 13:31:23 -07:00
|
|
|
therm_throt_process(msr_val &
|
2010-07-29 17:13:45 -07: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 13:31:23 -07:00
|
|
|
PACKAGE_LEVEL);
|
2010-07-29 17:13:44 -07:00
|
|
|
}
|
2009-06-15 17:25:27 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
static void unexpected_thermal_interrupt(void)
|
|
|
|
{
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_err("CPU%d: Unexpected LVT thermal interrupt!\n",
|
|
|
|
smp_processor_id());
|
2009-06-15 17:25:27 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
static void (*smp_thermal_vector)(void) = unexpected_thermal_interrupt;
|
|
|
|
|
2018-11-09 23:13:13 +01:00
|
|
|
asmlinkage __visible void __irq_entry smp_thermal_interrupt(struct pt_regs *regs)
|
x86, trace: Add irq vector tracepoints
[Purpose of this patch]
As Vaibhav explained in the thread below, tracepoints for irq vectors
are useful.
http://www.spinics.net/lists/mm-commits/msg85707.html
<snip>
The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled. They provide good data about when
the system has switched to kernel space and how it affects the currently
running processes.
There are some IRQ vectors which trigger the system into kernel space,
which are not handled in generic IRQ handlers. Tracing such events gives
us the information about IRQ interaction with other system events.
The trace also tells where the system is spending its time. We want to
know which cores are handling interrupts and how they are affecting other
processes in the system. Also, the trace provides information about when
the cores are idle and which interrupts are changing that state.
<snip>
On the other hand, my usecase is tracing just local timer event and
getting a value of instruction pointer.
I suggested to add an argument local timer event to get instruction pointer before.
But there is another way to get it with external module like systemtap.
So, I don't need to add any argument to irq vector tracepoints now.
[Patch Description]
Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
But there is an above use case to trace specific irq_vector rather than tracing all events.
In this case, we are concerned about overhead due to unwanted events.
So, add following tracepoints instead of introducing irq_vector_entry/exit.
so that we can enable them independently.
- local_timer_vector
- reschedule_vector
- call_function_vector
- call_function_single_vector
- irq_work_entry_vector
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
makes a zero when tracepoints are disabled. Detailed explanations are as follows.
- Create trace irq handlers with entering_irq()/exiting_irq().
- Create a new IDT, trace_idt_table, at boot time by adding a logic to
_set_gate(). It is just a copy of original idt table.
- Register the new handlers for tracpoints to the new IDT by introducing
macros to alloc_intr_gate() called at registering time of irq_vector handlers.
- Add checking, whether irq vector tracing is on/off, into load_current_idt().
This has to be done below debug checking for these reasons.
- Switching to debug IDT may be kicked while tracing is enabled.
- On the other hands, switching to trace IDT is kicked only when debugging
is disabled.
In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
used for other purposes.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
2013-06-20 11:46:53 -04:00
|
|
|
{
|
|
|
|
entering_irq();
|
|
|
|
trace_thermal_apic_entry(THERMAL_APIC_VECTOR);
|
2017-08-28 08:47:28 +02:00
|
|
|
inc_irq_stat(irq_thermal_count);
|
|
|
|
smp_thermal_vector();
|
x86, trace: Add irq vector tracepoints
[Purpose of this patch]
As Vaibhav explained in the thread below, tracepoints for irq vectors
are useful.
http://www.spinics.net/lists/mm-commits/msg85707.html
<snip>
The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled. They provide good data about when
the system has switched to kernel space and how it affects the currently
running processes.
There are some IRQ vectors which trigger the system into kernel space,
which are not handled in generic IRQ handlers. Tracing such events gives
us the information about IRQ interaction with other system events.
The trace also tells where the system is spending its time. We want to
know which cores are handling interrupts and how they are affecting other
processes in the system. Also, the trace provides information about when
the cores are idle and which interrupts are changing that state.
<snip>
On the other hand, my usecase is tracing just local timer event and
getting a value of instruction pointer.
I suggested to add an argument local timer event to get instruction pointer before.
But there is another way to get it with external module like systemtap.
So, I don't need to add any argument to irq vector tracepoints now.
[Patch Description]
Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
But there is an above use case to trace specific irq_vector rather than tracing all events.
In this case, we are concerned about overhead due to unwanted events.
So, add following tracepoints instead of introducing irq_vector_entry/exit.
so that we can enable them independently.
- local_timer_vector
- reschedule_vector
- call_function_vector
- call_function_single_vector
- irq_work_entry_vector
- error_apic_vector
- thermal_apic_vector
- threshold_apic_vector
- spurious_apic_vector
- x86_platform_ipi_vector
Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
makes a zero when tracepoints are disabled. Detailed explanations are as follows.
- Create trace irq handlers with entering_irq()/exiting_irq().
- Create a new IDT, trace_idt_table, at boot time by adding a logic to
_set_gate(). It is just a copy of original idt table.
- Register the new handlers for tracpoints to the new IDT by introducing
macros to alloc_intr_gate() called at registering time of irq_vector handlers.
- Add checking, whether irq vector tracing is on/off, into load_current_idt().
This has to be done below debug checking for these reasons.
- Switching to debug IDT may be kicked while tracing is enabled.
- On the other hands, switching to trace IDT is kicked only when debugging
is disabled.
In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
used for other purposes.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
2013-06-20 11:46:53 -04:00
|
|
|
trace_thermal_apic_exit(THERMAL_APIC_VECTOR);
|
|
|
|
exiting_ack_irq();
|
|
|
|
}
|
|
|
|
|
2009-12-14 17:57:00 +09:00
|
|
|
/* Thermal monitoring depends on APIC, ACPI and clock modulation */
|
|
|
|
static int intel_thermal_supported(struct cpuinfo_x86 *c)
|
|
|
|
{
|
2016-04-04 22:25:00 +02:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_APIC))
|
2009-12-14 17:57:00 +09:00
|
|
|
return 0;
|
|
|
|
if (!cpu_has(c, X86_FEATURE_ACPI) || !cpu_has(c, X86_FEATURE_ACC))
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-11-11 15:51:25 +08:00
|
|
|
void __init mcheck_intel_therm_init(void)
|
2009-11-10 09:38:24 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
*/
|
2009-12-14 17:57:00 +09:00
|
|
|
if (intel_thermal_supported(&boot_cpu_data))
|
2009-11-10 09:38:24 +08:00
|
|
|
lvtthmr_init = apic_read(APIC_LVTTHMR);
|
|
|
|
}
|
|
|
|
|
2009-11-12 15:52:40 +09:00
|
|
|
void intel_init_thermal(struct cpuinfo_x86 *c)
|
2009-06-15 17:26:10 +09:00
|
|
|
{
|
|
|
|
unsigned int cpu = smp_processor_id();
|
|
|
|
int tm2 = 0;
|
|
|
|
u32 l, h;
|
|
|
|
|
2009-12-14 17:57:00 +09:00
|
|
|
if (!intel_thermal_supported(c))
|
2009-06-15 17:26:10 +09: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 09:38:24 +08:00
|
|
|
|
2011-04-22 00:22:43 +08:00
|
|
|
h = lvtthmr_init;
|
2009-11-10 09:38:24 +08: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-22 00:22:43 +08: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 09:38:24 +08:00
|
|
|
*/
|
2011-04-22 00:22:43 +08:00
|
|
|
if ((h & APIC_DM_FIXED_MASK) != APIC_DM_FIXED)
|
|
|
|
apic_write(APIC_LVTTHMR, lvtthmr_init);
|
2009-11-10 09:38:24 +08:00
|
|
|
|
|
|
|
|
2009-06-15 17:26:10 +09:00
|
|
|
if ((l & MSR_IA32_MISC_ENABLE_TM1) && (h & APIC_DM_SMI)) {
|
2014-09-19 01:22:15 +06:00
|
|
|
if (system_state == SYSTEM_BOOTING)
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_debug("CPU%d: Thermal monitoring handled by SMI\n", cpu);
|
2009-06-15 17:26:10 +09:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-07-29 00:04:59 +02: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 17:26:10 +09: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);
|
|
|
|
|
|
|
|
rdmsr(MSR_IA32_THERM_INTERRUPT, l, h);
|
2013-05-21 15:35:17 -04:00
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable)
|
2010-07-29 17:13:45 -07:00
|
|
|
wrmsr(MSR_IA32_THERM_INTERRUPT,
|
2013-05-21 15:35:17 -04: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-29 17:13:45 -07:00
|
|
|
wrmsr(MSR_IA32_THERM_INTERRUPT,
|
2013-05-21 15:35:17 -04:00
|
|
|
l | (THERM_INT_LOW_ENABLE
|
2010-07-29 17:13:45 -07: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 17:26:10 +09:00
|
|
|
|
2010-07-29 17:13:44 -07:00
|
|
|
if (cpu_has(c, X86_FEATURE_PTS)) {
|
|
|
|
rdmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT, l, h);
|
2013-05-21 15:35:17 -04:00
|
|
|
if (cpu_has(c, X86_FEATURE_PLN) && !int_pln_enable)
|
2010-07-29 17:13:45 -07:00
|
|
|
wrmsr(MSR_IA32_PACKAGE_THERM_INTERRUPT,
|
2013-05-21 15:35:17 -04: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-29 17:13:45 -07: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);
|
2010-07-29 17:13:44 -07:00
|
|
|
}
|
|
|
|
|
2009-06-15 17:26:36 +09:00
|
|
|
smp_thermal_vector = intel_thermal_interrupt;
|
2009-06-15 17:26:10 +09:00
|
|
|
|
|
|
|
rdmsr(MSR_IA32_MISC_ENABLE, l, h);
|
|
|
|
wrmsr(MSR_IA32_MISC_ENABLE, l | MSR_IA32_MISC_ENABLE_TM1, h);
|
|
|
|
|
|
|
|
/* Unmask the thermal vector: */
|
|
|
|
l = apic_read(APIC_LVTTHMR);
|
|
|
|
apic_write(APIC_LVTTHMR, l & ~APIC_LVT_MASKED);
|
|
|
|
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_info_once("CPU0: Thermal monitoring enabled (%s)\n",
|
|
|
|
tm2 ? "TM2" : "TM1");
|
2009-06-15 17:26:10 +09:00
|
|
|
|
|
|
|
/* enable thermal throttle processing */
|
|
|
|
atomic_set(&therm_throt_en, 1);
|
|
|
|
}
|