> -----Original Message----- > From: lm-sensors-bounces@xxxxxxxxxxxxxx [mailto:lm-sensors- > bounces@xxxxxxxxxxxxxx] On Behalf Of Srinivas Pandruvada > Sent: Monday, April 15, 2013 8:51 PM > To: Guenter Roeck > Cc: Yu, Fenghua; Luck, Tony; linux-pm@xxxxxxxxxxxxxxx; lm-sensors@lm- > sensors.org; bp@xxxxxxxxx; Zhang, Rui > Subject: Re: [PATCH 0/4] thermal threshold and notification v2.0 > > 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. 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. Yes, this was the idea which we discussed in lm-sensors a few months ago. [I could not locate the thread in the web]. Except that we will register as 'thermal sensor' and not as 'thermal zones' because of the changes happening to the thermal framework recently[1]. This way, we can expose trip points and configure them, without having a need to associate any cdevs. [1] https://lkml.org/lkml/2013/2/5/228 Thanks, Durga > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > _______________________________________________ > lm-sensors mailing list > lm-sensors@xxxxxxxxxxxxxx > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
