linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Wei Wang <wvw@google.com>, linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Subject: Re: [PATCH 3/3] thermal/sysfs: Remove cooling device sysfs statistics
Date: Tue, 28 Jun 2022 17:26:05 +0200	[thread overview]
Message-ID: <0603d0e5-df0b-f47c-4391-b0860b07c13a@linaro.org> (raw)
In-Reply-To: <CAGXk5yqCNUpGpHkecVP8U=ys9NF6dJAMu6R0E+jpgvcSVFN+Ug@mail.gmail.com>

On 24/06/2022 08:02, Wei Wang wrote:
> On Fri, Jun 3, 2022 at 4:04 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>>
>>
>> Hi Todd,
>>
>> [adding Wei]
>>
>> On 02/06/2022 21:02, Todd Kjos wrote:
>>> On Thu, Jun 2, 2022 at 2:16 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> [ ... ]
>>
>>>> I see, it makes sense. Let's see if Todd and Android folks don't
>>>> use this thermal sysfs stats, so we could remove them.
>>>
>>> Android HALs do use the thermal sysfs stats. debugfs isn't a viable
>>> replacement since debugfs must not be mounted during normal operation.
>>
>> Thanks for your answer.
>>
>> I'm curious, what is the purpose of getting the statistics, especially
>> the transitions stats from normal operation?
>>
>> There were some complains about systems having a high number of cooling
>> devices with a lot of states. The state transitions are represented as a
>> matrix and result in up to hundred of megabytes of memory wasted.
>>
>> Moreover, sysfs being limited a page size, the output is often truncated.
>>
>> As it is automatically enabled for GKI, this waste of memory which is
>> not negligible for system with low memory can not be avoided.
>>
>> I went through the thermal HAL but did not find an usage of these
>> statistics, do you have a pointer to the code using them ?
>>
>> Thanks
>>
>>     -- Daniel
>>
>>
> 
> Sorry for the late reply, trying to catch up on emails after sick
> recovery. We use it for stats collection to understand thermal
> residency, and it is not in the HAL code, we don't use the transition
> table heavily though. Are some of the devices having too many cooling
> devices? Can we have a config to enable stats for a given cooling
> device?


The stats table is bogus. As soon as the combination of the states leads 
to a size greater than a page size, then the result is truncated.

As the cooling devices is also abused to mimic power capping capable 
device, we are ending up to 1024 states sometimes.

Moreover, having the option set also create tables which take MB of 
memory for nothing.

The option only enables the stats for all the cooling device stats.

As you mentioned, it seems to you are using the stats for debugging 
purpose. The debugfs provides the same information, except it does only 
show the transitions would actually happened and we are no longer 
limited to a page size.

Would it be acceptable to remove the sysfs stats ?



-- 
<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

      reply	other threads:[~2022-06-28 15:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01 15:14 [PATCH 1/3] thermal/core: Encapsulate the set_cur_state function Daniel Lezcano
2022-06-01 15:14 ` [PATCH 2/3] thermal/debugfs: Add debugfs information Daniel Lezcano
2022-06-01 22:55   ` kernel test robot
2022-06-02  0:39   ` kernel test robot
2022-06-02 20:20   ` kernel test robot
2022-06-01 15:14 ` [PATCH 3/3] thermal/sysfs: Remove cooling device sysfs statistics Daniel Lezcano
2022-06-01 15:33   ` Lukasz Luba
2022-06-02  8:37     ` Daniel Lezcano
2022-06-02  9:16       ` Lukasz Luba
2022-06-02 19:02         ` Todd Kjos
2022-06-03 11:04           ` Daniel Lezcano
2022-06-24  6:02             ` Wei Wang
2022-06-28 15:26               ` Daniel Lezcano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0603d0e5-df0b-f47c-4391-b0860b07c13a@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=wvw@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).