On 04/08/2013 09:45 AM, Guenter Roeck wrote:
On Mon, Apr 08, 2013 at 09:29:30AM -0700, Srinivas Pandruvada wrote:
Correction to my words.
On 04/08/2013 09:15 AM, Srinivas Pandruvada wrote:
Rafael, Len, Rui and Arjan,
Do you have any suggestions?
On 04/08/2013 08:26 AM, Guenter Roeck wrote:
On Sun, Apr 07, 2013 at 07:40:08PM -0700, Srinivas Pandruvada wrote:
Hi Guenter,
Thanks for your quick response. Please see my answers in-line.
Thanks,
Srinivas
On 04/05/2013 08:24 PM, Guenter Roeck wrote:
On Thu, Apr 04, 2013 at 01:09:20PM -0700, Srinivas Pandruvada wrote:
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"
I wasn't talking about ACPI, I was talking about the Linux
thermal subsystem
in drivers/thermal. There is no single mention of "ACPI" in
that directory.
<Thermal drivers also resides outside this directory. ACPI also
registers as thermal zone similar to other example you mentioned
below. ACPI is the only means to configure per platform thermal trip
points in thermal zones in PC platform.
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.
So, again, why can't you use the thermal subsystem ?
<Thermal zone needs to show temperature. This will be duplicate
what coretemp.X is showing. I want to prevent identical information
be displayed at two different sysfs>
Also the db8500 example you are giving, uses a pre-configured
thresholds loaded during probe().
There is no thermal ABI to set thresholds at run time. Basically
when a temperature is above a trip temp, corresponding cooling
devices will be activated.
So I still I have to write a platform driver to set thresholds, and
then registers with thermal zone. This will show as another
packagetemp.x at sysfs like coretemp.x.
So please let me know how to set dynamic thresholds?
The db8500_thermal driver in drivers/thermal is quite similar to what
you try to accomplish. I would suggest to look into it and
use a similar
approach. I really don't see how this fits into the hwmon subsystem.
<Is this logic based on that hwmon shouldn't have write interface
and used only for monitoring? I think some hwmon driver already
have write interface like gpiofan.>
That isn't the point. hwmon is static in nature, not dynamic.
Its scope is
hardware monitoring, not thermal management. This is what the
thermal subsystem
is for. Yes, presumably you would need a platform driver to set
the thresholds.
Another question, though, would be if you want or need a user
space component in
the first place or if you can implement all required
functionality in a thermal
driver.
Copying Zhang Rui and the linux-pm mailing list to get feedback
>from others.
We have debated user vs kernel space. Both are required.
There are many thermal modelling algorithms can be designed in
user space and it is already distributed by another OS to vendors.
User space can learn and model system based on usage. Kernel can
always act on well designed pre-configured or dynamically on
request.
My coretemp patches are not managing thermal, it is aiding in
thermal management as any other temperature sensor would do.
Let's restart. Pointing to [1], [2], and the related discussions, we left
at the time with no real user for the proposed new API as well as a lack of
its documented usage. Maybe we can start from there and add in the missing
details instead of rewriting everything.
<No problem. I just want to make sure that we have notification
mechanism and don't need to poll from user space for threshold.>
Thanks,
Guenter
[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2011-September/033808.html
[2] http://lists.lm-sensors.org/pipermail/lm-sensors/2012-May/036048.html
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
