Hi, On Mon, 2013-04-08 at 08:26 -0700, 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. > Agreed. I read the slides at https://github.com/01org/thermal_daemon/blob/master/ThermalDaemon_Introduction.pdf According to your slides, you have four kinds of cooling devices, 1. RAPL cooling device driver 2. P states control 3. Intel power clamp driver 4. T states and four trip points (according to the picture in page 9). I think you will use, say RAPL for trip point 0 (the bigger the number is, the higher temperature the trip point is), both RAPL and P state control for trip point1, ..., all of the cooling devices for trip point 3, etc, right? IMO, all of these actions fit into the Linux/Thermal subsystem naturally. so my question would be why do you prefer to do it by user space component? thanks, rui _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
