| Message ID | 1457979156-10972-1-git-send-email-srikars@nvidia.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Zhang Rui |
| Headers | show |
On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: > Add a sysfs_notify on thermal_zone*/temp and cooling_device*/ > cur_state whenever any trip is triggered or cur state is changed. > > This change allows usermode apps to register themselves to get > notified, when certain thermal conditions occur and reduce their > workload. This workload throttling allows usermode to react before > hardware clocks are throttled and keep some critical apps running > reliably longer. I think we need a combination of proposal in https://patchwork.kernel.org/patch/7876351/ and this. For example this patch notifies that some trip is violated, but that is not enough for user space application to take any action. Some trips violations user space may not care as this may be a transient one. The patch from Eduardo address that by providing trip, temperature and last temperature information. But that patch only address hot trips. I understand why Eduardo doesn't want to be notified for passive trips as there will be too many. So IMO we need some mechanism to turn off notification and decide what notification will result in user space notifications. On some x86 systems we have 10+ passive/active trips, this will results in too many notifications. We may be in thermally sensitive zone, where more code excecution is more heat. We may have some mask of trips for which will result in notifications. By default no notifications, unless some user space requests. During last LPC we discussed about using IIO for temperature threshold notifications and I submitted multiple changes for that. Looks like we also care of trip point changes. So I think we need more comprehensive mechanism to address this. May be we should have thermal mini summit during LPC again and decide a comprehensive plan to address all asynchronous thermal notifications. Thanks, Srinivas > > Signed-off-by: Srikar Srimath Tirumala <srikars@nvidia.com> > --- > > Changes from v1: > - Calling sysfs_notify for thermal_zone*/temp only when there is a > trip violated on the thermal zone. > - Modified commit message. > > drivers/thermal/thermal_core.c | 34 ++++++++++++++++++++++++++---- > ---- > 1 file changed, 26 insertions(+), 8 deletions(-) > > diff --git a/drivers/thermal/thermal_core.c > b/drivers/thermal/thermal_core.c > index a0a8fd1..f54519e 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -419,14 +419,23 @@ static void monitor_thermal_zone(struct > thermal_zone_device *tz) > mutex_unlock(&tz->lock); > } > > -static void handle_non_critical_trips(struct thermal_zone_device > *tz, > +static int handle_non_critical_trips(struct thermal_zone_device *tz, > int trip, enum thermal_trip_type trip_type) > { > + int trip_temp; > + int ret = 0; > + > tz->governor ? tz->governor->throttle(tz, trip) : > def_governor->throttle(tz, trip); > + > + tz->ops->get_trip_temp(tz, trip, &trip_temp); > + if (tz->temperature >= trip_temp) > + ret = 1; > + > + return ret; > } > > -static void handle_critical_trips(struct thermal_zone_device *tz, > +static int handle_critical_trips(struct thermal_zone_device *tz, > int trip, enum thermal_trip_type > trip_type) > { > int trip_temp; > @@ -435,7 +444,7 @@ static void handle_critical_trips(struct > thermal_zone_device *tz, > > /* If we have not crossed the trip_temp, we do not care. */ > if (trip_temp <= 0 || tz->temperature < trip_temp) > - return; > + return 0; > > trace_thermal_zone_trip(tz, trip, trip_type); > > @@ -448,23 +457,28 @@ static void handle_critical_trips(struct > thermal_zone_device *tz, > tz->temperature / 1000); > orderly_poweroff(true); > } > + > + return 1; > } > > -static void handle_thermal_trip(struct thermal_zone_device *tz, int > trip) > +static int handle_thermal_trip(struct thermal_zone_device *tz, int > trip) > { > + int ret = 0; > enum thermal_trip_type type; > > tz->ops->get_trip_type(tz, trip, &type); > > if (type == THERMAL_TRIP_CRITICAL || type == > THERMAL_TRIP_HOT) > - handle_critical_trips(tz, trip, type); > + ret = handle_critical_trips(tz, trip, type); > else > - handle_non_critical_trips(tz, trip, type); > + ret = handle_non_critical_trips(tz, trip, type); > /* > * Alright, we handled this trip successfully. > * So, start monitoring again. > */ > monitor_thermal_zone(tz); > + > + return ret; > } > > /** > @@ -556,7 +570,7 @@ static void thermal_zone_device_reset(struct > thermal_zone_device *tz) > void thermal_zone_device_update(struct thermal_zone_device *tz) > { > int count; > - > + int trips = 0; > if (atomic_read(&in_suspend)) > return; > > @@ -566,7 +580,10 @@ void thermal_zone_device_update(struct > thermal_zone_device *tz) > update_temperature(tz); > > for (count = 0; count < tz->trips; count++) > - handle_thermal_trip(tz, count); > + trips += handle_thermal_trip(tz, count); > + > + if (trips) > + sysfs_notify(&tz->device.kobj, NULL, "temp"); > } > EXPORT_SYMBOL_GPL(thermal_zone_device_update); > > @@ -1638,6 +1655,7 @@ void thermal_cdev_update(struct > thermal_cooling_device *cdev) > cdev->updated = true; > trace_cdev_update(cdev, target); > dev_dbg(&cdev->device, "set to state %lu\n", target); > + sysfs_notify(&cdev->device.kobj, NULL, "cur_state"); > } > EXPORT_SYMBOL(thermal_cdev_update); >
On Tue, Mar 15, 2016 at 11:08:00PM +0000, Pandruvada, Srinivas wrote: > On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: > > Add a sysfs_notify on thermal_zone*/temp and cooling_device*/ > > cur_state whenever any trip is triggered or cur state is changed. > > > > This change allows usermode apps to register themselves to get > > notified, when certain thermal conditions occur and reduce their > > workload. This workload throttling allows usermode to react before > > hardware clocks are throttled and keep some critical apps running > > reliably longer. > I think we need a combination of proposal in > https://patchwork.kernel.org/patch/7876351/ and this. > > For example this patch notifies that some trip is violated, but that is > not enough for user space application to take any action. Some trips > violations user space may not care as this may be a transient one. The > patch from Eduardo address that by providing trip, temperature and last > temperature information. But that patch only address hot trips. I > understand why Eduardo doesn't want to be notified for passive trips as > there will be too many. > Yeah, my original intention was to avoid flooding userland, specially through a pipe like the sysfs netlink, which is in use to deal with other stuff. > So IMO we need some mechanism to turn off notification and decide what > notification will result in user space notifications. > On some x86 systems we have 10+ passive/active trips, this will results > in too many notifications. We may be in thermally sensitive zone, where > more code excecution is more heat. > Exactly, that has direct impact not only on the process waiting for thermal notifications, but also on other process listening to sysfs. > We may have some mask of trips for which will result in notifications. > By default no notifications, unless some user space requests. > The complexity of such communication (or even the current status of sysfs ABI) starts to reach limit of such channel. We may definitely consider other means, such as /dev interface, just like IIO does. > During last LPC we discussed about using IIO for temperature threshold > notifications and I submitted multiple changes for that. Looks like we > also care of trip point changes. So I think we need more comprehensive > mechanism to address this. > > May be we should have thermal mini summit during LPC again and decide a > comprehensive plan to address all asynchronous thermal notifications. > I have created a wiki for LPC 2016 http://wiki.linuxplumbersconf.org/2016:thermal Overall I believe we need to solve the (temperature) sensing in a more structured way within the kernel. We have three subsystem that allow performing temperature sensing. They are different in design and concept, but still solve similar problems. I would still prefer to get this better architectured. Of course, we do not need to wait until LPC to start drafting this. Again, please lets generate enough quorum to run the micro conf. BR, Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/28/2016 06:35 PM, Eduardo Valentin wrote: > On Tue, Mar 15, 2016 at 11:08:00PM +0000, Pandruvada, Srinivas wrote: >> On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: >>> Add a sysfs_notify on thermal_zone*/temp and cooling_device*/ >>> cur_state whenever any trip is triggered or cur state is changed. >>> >>> This change allows usermode apps to register themselves to get >>> notified, when certain thermal conditions occur and reduce their >>> workload. This workload throttling allows usermode to react before >>> hardware clocks are throttled and keep some critical apps running >>> reliably longer. >> I think we need a combination of proposal in >> https://patchwork.kernel.org/patch/7876351/ and this. >> >> For example this patch notifies that some trip is violated, but that is >> not enough for user space application to take any action. Some trips >> violations user space may not care as this may be a transient one. The >> patch from Eduardo address that by providing trip, temperature and last >> temperature information. But that patch only address hot trips. I >> understand why Eduardo doesn't want to be notified for passive trips as >> there will be too many. >> > > Yeah, my original intention was to avoid flooding userland, specially > through a pipe like the sysfs netlink, which is in use to deal with > other stuff. > How about if the number of notifications were to be reduced like in v3 of this patch? Or is the consensus not to use sysfs_notify or uevents at all? >> So IMO we need some mechanism to turn off notification and decide what >> notification will result in user space notifications. >> On some x86 systems we have 10+ passive/active trips, this will results >> in too many notifications. We may be in thermally sensitive zone, where >> more code excecution is more heat. >> > > Exactly, that has direct impact not only on the process waiting for > thermal notifications, but also on other process listening to sysfs. > >> We may have some mask of trips for which will result in notifications. >> By default no notifications, unless some user space requests. >> > > The complexity of such communication (or even the current status of > sysfs ABI) starts to reach limit of such channel. We may definitely > consider other means, such as /dev interface, just like IIO does. > I agree with your point about the overhead of generating these events and thought maybe the problem could be partially addressed by reducing the number of notifications being sent. So with that in mind I created a V3 of the patches which does this. Please do take a look at it when you get a chance. >> During last LPC we discussed about using IIO for temperature threshold >> notifications and I submitted multiple changes for that. Looks like we >> also care of trip point changes. So I think we need more comprehensive >> mechanism to address this. >> >> May be we should have thermal mini summit during LPC again and decide a >> comprehensive plan to address all asynchronous thermal notifications. >> > > I have created a wiki for LPC 2016 > http://wiki.linuxplumbersconf.org/2016:thermal > > Overall I believe we need to solve the (temperature) sensing in a more > structured way within the kernel. We have three subsystem that allow > performing temperature sensing. They are different in design and > concept, but still solve similar problems. > I went through the LPC presentation/patches and had a couple of questions. The thermal iio device seems perfectly suited for sending large amounts of thermal data from the kernel framework to user space. Are there a lot of platforms where thermal throttling happens in user space? If so, Is this an indication that passive thermal throttling is going into the user space some time in the future? Our use cases don't really require too many notifications. But there seem to be other use cases out there that require lot more thermal info from the kernel. Just trying to understand what those are and what needs to be done to arrive at a solution that benefits all. > I would still prefer to get this better architectured. > > Of course, we do not need to wait until LPC to start drafting this. > > Again, please lets generate enough quorum to run the micro conf. > > BR, > > Eduardo Valentin > Much appreciate your comments and inputs. Best Regards Srikar -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2016-03-29 at 19:53 -0700, Srikar Srimath Tirumala wrote: > On 03/28/2016 06:35 PM, Eduardo Valentin wrote: > > > > On Tue, Mar 15, 2016 at 11:08:00PM +0000, Pandruvada, Srinivas > > wrote: > > > > > > On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: [...] > > I have created a wiki for LPC 2016 > > http://wiki.linuxplumbersconf.org/2016:thermal > > > > Overall I believe we need to solve the (temperature) sensing in a > > more > > structured way within the kernel. We have three subsystem that > > allow > > performing temperature sensing. They are different in design and > > concept, but still solve similar problems. > > > I went through the LPC presentation/patches and had a couple of > questions. > > The thermal iio device seems perfectly suited for sending large > amounts > of thermal data from the kernel framework to user space. Are there a > lot > of platforms where thermal throttling happens in user space? Yes. > If so, Is > this an indication that passive thermal throttling is going into the > user space some time in the future? Not really. Kernel takes care about more immediate/urgent needs. User space is more about long term control, where you will prevent aggressive controls from kernel. Thanks, Srinivas
On Mon, 2016-03-28 at 18:35 -0700, Eduardo Valentin wrote: > On Tue, Mar 15, 2016 at 11:08:00PM +0000, Pandruvada, Srinivas wrote: > > > > On Mon, 2016-03-14 at 11:12 -0700, Srikar Srimath Tirumala wrote: > > > > > > [...] > > > The complexity of such communication (or even the current status of > sysfs ABI) starts to reach limit of such channel. We may definitely > consider other means, such as /dev interface, just like IIO does. Yes. Instead of loading netlink I/F, we need to have thermal channel to notify. > > During last LPC we discussed about using IIO for temperature > > threshold > > notifications and I submitted multiple changes for that. Looks like > > we > > also care of trip point changes. So I think we need more > > comprehensive > > mechanism to address this. > > > > May be we should have thermal mini summit during LPC again and > > decide a > > comprehensive plan to address all asynchronous thermal > > notifications. > > > I have created a wiki for LPC 2016 > http://wiki.linuxplumbersconf.org/2016:thermal > > Overall I believe we need to solve the (temperature) sensing in a > more > structured way within the kernel. We have three subsystem that allow > performing temperature sensing. They are different in design and > concept, but still solve similar problems. > > Again, please lets generate enough quorum to run the micro conf. > I am planning to attend. Thanks, Srinivas > BR, > > Eduardo Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index a0a8fd1..f54519e 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -419,14 +419,23 @@ static void monitor_thermal_zone(struct thermal_zone_device *tz) mutex_unlock(&tz->lock); } -static void handle_non_critical_trips(struct thermal_zone_device *tz, +static int handle_non_critical_trips(struct thermal_zone_device *tz, int trip, enum thermal_trip_type trip_type) { + int trip_temp; + int ret = 0; + tz->governor ? tz->governor->throttle(tz, trip) : def_governor->throttle(tz, trip); + + tz->ops->get_trip_temp(tz, trip, &trip_temp); + if (tz->temperature >= trip_temp) + ret = 1; + + return ret; } -static void handle_critical_trips(struct thermal_zone_device *tz, +static int handle_critical_trips(struct thermal_zone_device *tz, int trip, enum thermal_trip_type trip_type) { int trip_temp; @@ -435,7 +444,7 @@ static void handle_critical_trips(struct thermal_zone_device *tz, /* If we have not crossed the trip_temp, we do not care. */ if (trip_temp <= 0 || tz->temperature < trip_temp) - return; + return 0; trace_thermal_zone_trip(tz, trip, trip_type); @@ -448,23 +457,28 @@ static void handle_critical_trips(struct thermal_zone_device *tz, tz->temperature / 1000); orderly_poweroff(true); } + + return 1; } -static void handle_thermal_trip(struct thermal_zone_device *tz, int trip) +static int handle_thermal_trip(struct thermal_zone_device *tz, int trip) { + int ret = 0; enum thermal_trip_type type; tz->ops->get_trip_type(tz, trip, &type); if (type == THERMAL_TRIP_CRITICAL || type == THERMAL_TRIP_HOT) - handle_critical_trips(tz, trip, type); + ret = handle_critical_trips(tz, trip, type); else - handle_non_critical_trips(tz, trip, type); + ret = handle_non_critical_trips(tz, trip, type); /* * Alright, we handled this trip successfully. * So, start monitoring again. */ monitor_thermal_zone(tz); + + return ret; } /** @@ -556,7 +570,7 @@ static void thermal_zone_device_reset(struct thermal_zone_device *tz) void thermal_zone_device_update(struct thermal_zone_device *tz) { int count; - + int trips = 0; if (atomic_read(&in_suspend)) return; @@ -566,7 +580,10 @@ void thermal_zone_device_update(struct thermal_zone_device *tz) update_temperature(tz); for (count = 0; count < tz->trips; count++) - handle_thermal_trip(tz, count); + trips += handle_thermal_trip(tz, count); + + if (trips) + sysfs_notify(&tz->device.kobj, NULL, "temp"); } EXPORT_SYMBOL_GPL(thermal_zone_device_update); @@ -1638,6 +1655,7 @@ void thermal_cdev_update(struct thermal_cooling_device *cdev) cdev->updated = true; trace_cdev_update(cdev, target); dev_dbg(&cdev->device, "set to state %lu\n", target); + sysfs_notify(&cdev->device.kobj, NULL, "cur_state"); } EXPORT_SYMBOL(thermal_cdev_update);
Add a sysfs_notify on thermal_zone*/temp and cooling_device*/ cur_state whenever any trip is triggered or cur state is changed. This change allows usermode apps to register themselves to get notified, when certain thermal conditions occur and reduce their workload. This workload throttling allows usermode to react before hardware clocks are throttled and keep some critical apps running reliably longer. Signed-off-by: Srikar Srimath Tirumala <srikars@nvidia.com> --- Changes from v1: - Calling sysfs_notify for thermal_zone*/temp only when there is a trip violated on the thermal zone. - Modified commit message. drivers/thermal/thermal_core.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-)