Hi,
the userspace governor is sending temperature when polling is active and
trip point crossed events. Nothing else.
In the other side, the cooling device have their cooling device
set_cur_state read-writable all the time.
The thermal framework is wrongly used by userspace as a power capping
framework by acting on the cooling device opaque state. This one then
competes with the in-kernel governor decision.
As the new netlink thermal notification is able to provide the same
information than the userspace governor.
I propose to remove the userspace governor and the cur_state entry in
the sysfs exported file.
The DTPM framework is the right framework to do power capping and
moreover it deals with the aggregation via the dev pm qos.
Does it make sense ?
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hi Daniel,
On 9/22/21 10:59 AM, Daniel Lezcano wrote:
>
> Hi,
>
> the userspace governor is sending temperature when polling is active and
> trip point crossed events. Nothing else.
>
> In the other side, the cooling device have their cooling device
> set_cur_state read-writable all the time.
>
> The thermal framework is wrongly used by userspace as a power capping
> framework by acting on the cooling device opaque state. This one then
> competes with the in-kernel governor decision.
>
> As the new netlink thermal notification is able to provide the same
> information than the userspace governor.
>
> I propose to remove the userspace governor and the cur_state entry in
> the sysfs exported file.
>
> The DTPM framework is the right framework to do power capping and
> moreover it deals with the aggregation via the dev pm qos.
>
> Does it make sense ?
It sounds that we should be OK with the information from netlink.
I don't see objections. We can also extend the netlink packet when
needed. I'm fine with removing the user-space governor.
Regards,
Lukasz
On 10/1/21 11:30 AM, Daniel Lezcano wrote:
>
> Hi Lukasz,
>
> On 30/09/2021 12:10, Lukasz Luba wrote:
>> Hi Daniel,
>>
>> On 9/22/21 10:59 AM, Daniel Lezcano wrote:
>>>
>>> Hi,
>>>
>>> the userspace governor is sending temperature when polling is active and
>>> trip point crossed events. Nothing else.
>>>
>>> In the other side, the cooling device have their cooling device
>>> set_cur_state read-writable all the time.
>>>
>>> The thermal framework is wrongly used by userspace as a power capping
>>> framework by acting on the cooling device opaque state. This one then
>>> competes with the in-kernel governor decision.
>>>
>>> As the new netlink thermal notification is able to provide the same
>>> information than the userspace governor.
>>>
>>> I propose to remove the userspace governor and the cur_state entry in
>>> the sysfs exported file.
>>>
>>> The DTPM framework is the right framework to do power capping and
>>> moreover it deals with the aggregation via the dev pm qos.
>>>
>>> Does it make sense ?
>>
>> It sounds that we should be OK with the information from netlink.
>> I don't see objections. We can also extend the netlink packet when
>> needed. I'm fine with removing the user-space governor.
>
> thank you for your answer. I'll propose a patch with a warn when the
> userspace governor is registered in order to let know people the
> governor is deprecated.
>
> Probably, it would make sense to emit a warning also when the cooling
> device state is set from userspace.
>
> For the next release, we should be able to drop the userspace governor
> and make the cooling device state read-only.
>
> Does it make sense ?
>
>
Yes, it makes sense.
Hi Lukasz,
On 30/09/2021 12:10, Lukasz Luba wrote:
> Hi Daniel,
>
> On 9/22/21 10:59 AM, Daniel Lezcano wrote:
>>
>> Hi,
>>
>> the userspace governor is sending temperature when polling is active and
>> trip point crossed events. Nothing else.
>>
>> In the other side, the cooling device have their cooling device
>> set_cur_state read-writable all the time.
>>
>> The thermal framework is wrongly used by userspace as a power capping
>> framework by acting on the cooling device opaque state. This one then
>> competes with the in-kernel governor decision.
>>
>> As the new netlink thermal notification is able to provide the same
>> information than the userspace governor.
>>
>> I propose to remove the userspace governor and the cur_state entry in
>> the sysfs exported file.
>>
>> The DTPM framework is the right framework to do power capping and
>> moreover it deals with the aggregation via the dev pm qos.
>>
>> Does it make sense ?
>
> It sounds that we should be OK with the information from netlink.
> I don't see objections. We can also extend the netlink packet when
> needed. I'm fine with removing the user-space governor.
thank you for your answer. I'll propose a patch with a warn when the
userspace governor is registered in order to let know people the
governor is deprecated.
Probably, it would make sense to emit a warning also when the cooling
device state is set from userspace.
For the next release, we should be able to drop the userspace governor
and make the cooling device state read-only.
Does it make sense ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog