On Tue, Apr 16, 2013 at 12:52:43PM +0800, Zhang Rui wrote: > On Mon, 2013-04-15 at 08:20 -0700, Srinivas Pandruvada wrote: > > On 04/12/2013 06:32 PM, Guenter Roeck wrote: > > > On Tue, Apr 09, 2013 at 02:01:18PM -0700, Srinivas Pandruvada wrote: > > >> v2.0 > > >> As suggested by Guenter Roeck, used the previous development in this area > > >> as starting point. The first patch is same as what Guenter Roeck submitted > > >> before except for checkpatch error for strtoul.As per this patch, the following > > >> additional coretemp sysfs entries will be added: > > >> tempX_threshold1 - Reflects value of CPU thermal threshold T0. > > >> tempX_threshold1_triggered > > >> - Reflects status of CPU thermal status register bit 6 > > >> (THERM_STATUS_THRESHOLD0). > > >> tempX_threshold2 - Reflects value of CPU thermal threshold T1. > > >> tempX_threshold2_triggered > > >> - Reflects status of CPU thermal status register bit 8 > > >> (THERM_STATUS_THRESHOLD1). > > >> > > >> > > >> The notification mechanism is implemented for package level by using uevent. > > >> Also a debugfs interface is added to check count of interrupts and worker fn > > >> scheduling. > > >> > > >> > > >> v1.0 > > >> > > >> 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. > > >> > > >> Notification are added only for package level thresholds, to minimize events. Also > > >> interrupts are enabled only when a non tj_max(default) 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.* > > >> > > >> Guenter Roeck (1): > > >> hwmon: (coretemp) Add support for thermal threshold attributes > > >> > > >> Srinivas Pandruvada (3): > > >> x86, mcheck, therm_throt: Process package thresholds > > >> hwmon: (coretemp) : Add notification support > > >> hwmon: (coretemp) : Add debugfs to support thresholds > > >> > > >> Documentation/hwmon/coretemp | 8 + > > >> arch/x86/include/asm/mce.h | 7 + > > >> arch/x86/kernel/cpu/mcheck/therm_throt.c | 63 ++++++- > > >> drivers/hwmon/coretemp.c | 292 +++++++++++++++++++++++++++++-- > > >> 4 files changed, 356 insertions(+), 14 deletions(-) > > >> > > > Rui, > > > > > > can you have a look at this series ? > > > > > > I would like to get some feedback from thermal subsystem supporters if hwmon > > > is really the right place for this. I may be wrong, but it seems to me it would > > > better fit into thermal. > > > > > > Thanks, > > > Guenter > > > > I am fine using thermal zones, but the coretemp will be duplicated in > > both coretemp and thermal sysfs and lot of code duplication. > > is it possible to introduce code in coretemp driver to register with > thermal subsystem? > Should be possible. As mentioned in my other mail, I think we should find some automated way to do that (ie in the infrastructure), but that is something we can deal with later on. Guenter > > Also trip > > point in this case is not for activating any cooling device, but just to > > notify user space. So this will be a zone with no associated cdevs. > > > trip points for thermal zones does not have to bind with cdevs. > if you bind the p-state driver, rapl, intel_powerclamp and t-state > driver to this thermal zone, all the thermal management work can be done > in kernel. > But if you do not bind any cooling devices to trip points, you can use > "userspace" thermal governor, and provide your own > thermal_zone_device_ops->notify() callback. > In this case, .notify() will be called instead, and you can do whatever > you want in that callback. > > thanks, > rui > > _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
