All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH 0/4] thermal threshold event notification
Date: Thu, 04 Apr 2013 20:09:20 +0000	[thread overview]
Message-ID: <515DDDF0.9020904@linux.intel.com> (raw)
In-Reply-To: <1365102689-12581-1-git-send-email-srinivas.pandruvada@linux.intel.com>

On 04/04/2013 12:43 PM, Guenter Roeck wrote:
> On Thu, Apr 04, 2013 at 12:11:25PM -0700, Srinivas Pandruvada wrote:
>> This is clear that there is reluctance in adding thresholds in coretemp sysfs,
>> during previous attempts. Proably because of lake of use cases.
>> But this time use case may be more compelling.
>>
>> We have many small form factor devices like ultrabooks, slate PCs in the market.
>> Unfortunately these devices reach maximum temperature with relatively less
>> workloads, causing BIOS to do thermal throttling. There are real performance
>> issues due to aggressive BIOS action to control thermals and also thermal breakdown
>> in some cases.
>>
>> Even the most expensive laptops, don't have correct ACPI thermal configuration,
>> so that kernel thermal driver can act. In some case even the trip point is higher
>> than critical temperature setting.
>>
>> Intel has developed several drivers, which can be used to cool the system very efficiently.
>> They include RAPL based cooling driver, Powerclamp driver and P state driver.
>> To utilize these cooling device a closed loop user mode program is required, which
>> will utilize these method and dynamically compensate for high CPU temperatures,
>> without relying on any configuration data.
>> One such solution is developed is "Linux thermal daemon". More details can be
>> obtained from
>> "https://github.com/01org/thermal_daemon/blob/master/ThermalDaemon_Introduction.pdf".
>> This daemon polls for cpu temperature and apply compensation once the CPU reach target
>> temperature.
>>
>> This polling can be mostly avoided, by getting notification for the temperature, where
>> it needs to wake up and get ready for apply compensation. In most of the normal use
>> cases, there may not be any threshold events. So very minimal number of user space
>> notification for thermal thresholds.
>>
>>   
>> This patch adds two entries to coretemp sysfs.
>> tempX_notify_threshold_1
>> tempX_notify_threshold_2
>>
>> These two settings acts on "Package level", not on core level. So it will only appear
>> if there is support for package temperature. Many of recent Intel processors, support
>> package temperatures
>> When any valid value is written to these files, it will directly set corresponding CPU MSR,
>> in the corresponding package and read back directly from MSR. Since package MSR, affects
>> all cores in package, setting will be applicable to all CPU's in the package minimizing
>> read, writes and notifications. Also package threshold interrupts are enabled only when,
>> a non zero value is written to thresholds.
>>
>> Once thresholds are violated, it uses a rate control of 5 seconds, reducing the number
>> of interrupts, when temperature is hanging around trip point. Using the sticky log bit,
>> it sends kboject uevent change notification for corresponding package sysfs.
>> Once the thermal daemon receives notification, it can change to new threshold or act
>> immediately to reduce CPU temperature.
>>
>>
>> Srinivas Pandruvada (4):
>>    x86, mcheck, therm_throt: Process package thresholds
>>    hwmon: (coretemp) Add threshold support
>>    hwmon: (coretemp) : Add notification support
>>    drivers/hwmon/coretemp : Debug fs interface
>>
>>   arch/x86/include/asm/mce.h               |   7 +
>>   arch/x86/kernel/cpu/mcheck/therm_throt.c |  50 ++++-
>>   drivers/hwmon/coretemp.c                 | 319 +++++++++++++++++++++++++++++--
>>   3 files changed, 361 insertions(+), 15 deletions(-)
>>
> Key question: Why does the thermal subsystem not work for you ?
Thermal is bigger issue in Ultrabooks, Slate PCs and other small form 
factor devices.
Linux ACPI thermal driver depends on ACPI configuration to activate 
active/passive control. So if you have garbage data or not optimized 
data, the current Linux driver can't control thermals. There are 
multiple platforms with bad ACPI data. Some of them have "ACPI threshold 
 > critical temp"

Currently all these systems, rely on BIOS fan and T state control. Once 
T states are used the performance gets hurt. Also we had cases of 
thermal breakdown.

In addition there are several new methods to cool the system, developed 
by Intel and are in latest Linux kernel. They are specially designed to 
cool the system when needed.

Thermal daemon uses a close loop control using all available means to 
control CPU temperature, before BIOS do T states.

Also targeting fan-less systems, which will be overheating.

> Thanks,
> Guenter
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2013-04-04 20:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-04 19:11 [lm-sensors] [PATCH 0/4] thermal threshold event notification Srinivas Pandruvada
2013-04-04 19:43 ` Guenter Roeck
2013-04-04 20:09 ` Srinivas Pandruvada [this message]
2013-04-06  3:24 ` Guenter Roeck
2013-04-08  2:40 ` Srinivas Pandruvada
2013-04-08 15:26   ` Guenter Roeck
2013-04-08 15:26     ` [lm-sensors] " Guenter Roeck
2013-04-08 16:15     ` Srinivas Pandruvada
2013-04-08 16:15       ` [lm-sensors] " Srinivas Pandruvada
2013-04-16  4:41       ` Zhang Rui
2013-04-16  4:41         ` [lm-sensors] " Zhang Rui
2013-04-16  4:01     ` Zhang Rui
2013-04-16  4:01       ` [lm-sensors] " Zhang Rui
2013-04-16  4:53       ` Guenter Roeck
2013-04-16  4:53         ` [lm-sensors] " Guenter Roeck
2013-04-16  5:05         ` Zhang Rui
2013-04-16  5:05           ` [lm-sensors] " Zhang Rui
2013-04-08 16:29 ` Srinivas Pandruvada
2013-04-08 16:45 ` Guenter Roeck
2013-04-08 16:59 ` Srinivas Pandruvada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=515DDDF0.9020904@linux.intel.com \
    --to=srinivas.pandruvada@linux.intel.com \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.