From: Pavel Machek <pavel@ucw.cz>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: edubezval@gmail.com, kevin.wangtao@linaro.org,
leo.yan@linaro.org, vincent.guittot@linaro.org,
amit.kachhap@gmail.com, linux-kernel@vger.kernel.org,
javi.merino@kernel.org, rui.zhang@intel.com,
daniel.thompson@linaro.org, linux-pm@vger.kernel.org,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH V2 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation
Date: Thu, 8 Mar 2018 09:59:49 +0100 [thread overview]
Message-ID: <20180308085949.GB17761@amd> (raw)
In-Reply-To: <84fa8a3c-28bf-41ae-8ed7-9dd348b1cde9@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 3812 bytes --]
Hi!
> >> +Under certain circumstances, the SoC reaches a temperature exceeding
> >> +the allocated power budget or the maximum temperature limit. The
> >
> > I don't understand. Power budget is in W, temperature is in
> > kelvin. Temperature can't exceed power budget AFAICT.
>
> Yes, it is badly worded. Is the following better ?
>
> "
> Under certain circumstances a SoC can reach the maximum temperature
> limit or is unable to stabilize the temperature around a temperature
> control.
>
> When the SoC has to stabilize the temperature, the kernel can act on a
> cooling device to mitigate the dissipated power.
>
> When the maximum temperature is reached and to prevent a catastrophic
> situation a radical decision must be taken to reduce the temperature
> under the critical threshold, that impacts the performance.
>
> "
Actually... if hardware is expected to protect itself, I'd tone it
down. No need to be all catastrophic and critical... But yes, better.
> > Critical here, critical there. I have trouble following
> > it. Theoretically hardware should protect itself, because you don't
> > want kernel bug to damage your CPU?
>
> There are several levels of protection. The first level is mitigating
> the temperature from the kernel, then in the temperature sensor a reset
> line will trigger the reboot of the CPUs. Usually it is a register where
> you write the maximum temperature, from the driver itself. I never tried
> to write 1000°C in this register and see if I can burn the board.
>
> I know some boards have another level of thermal protection in the
> hardware itself and some other don't.
>
> In any case, from a kernel point of view, it is a critical situation as
> we are about to hard reboot the system and in this case it is preferable
> to drop drastically the performance but give the opportunity to the
> system to run in a degraded mode.
Agreed you want to keep going. In ACPI world, we shutdown when
critical trip point is reached, so this is somehow confusing.
> >> +Solutions:
> >> +----------
> >> +
> >> +If we can remove the static and the dynamic leakage for a specific
> >> +duration in a controlled period, the SoC temperature will
> >> +decrease. Acting at the idle state duration or the idle cycle
> >
> > "should" decrease? If you are in bad environment..
>
> No, it will decrease in any case because of the static leakage drop. The
> bad environment will impact the speed of this decrease.
I meant... if ambient temperature is 105C, there's not much you can do
to cool system down :-).
> >> +Idle Injection:
> >> +---------------
> >> +
> >> +The base concept of the idle injection is to force the CPU to go to an
> >> +idle state for a specified time each control cycle, it provides
> >> +another way to control CPU power and heat in addition to
> >> +cpufreq. Ideally, if all CPUs of a cluster inject idle synchronously,
> >> +this cluster can get into the deepest idle state and achieve minimum
> >> +power consumption, but that will also increase system response latency
> >> +if we inject less than cpuidle latency.
> >
> > I don't understand last sentence.
>
> Is it better ?
>
> "Ideally, if all CPUs, belonging to the same cluster, inject their idle
> cycle synchronously, the cluster can reach its power down state with a
> minimum power consumption and static leakage drop. However, these idle
> cycles injection will add extra latencies as the CPUs will have to
> wakeup from a deep sleep state."
Extra comma "CPUs , belonging". But yes, better.
> Thanks!
You are welcome. Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-03-08 8:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1519226968-19821-1-git-send-email-daniel.lezcano@linaro.org>
[not found] ` <1519226968-19821-6-git-send-email-daniel.lezcano@linaro.org>
2018-03-06 23:19 ` [PATCH V2 5/7] thermal/drivers/cpu_cooling: Add idle cooling device documentation Pavel Machek
2018-03-07 11:42 ` Daniel Lezcano
2018-03-08 8:59 ` Pavel Machek [this message]
2018-03-08 11:54 ` Daniel Thompson
2018-03-07 17:09 ` [PATCH V2 0/7] CPU cooling device new strategies Eduardo Valentin
2018-03-07 18:57 ` Daniel Lezcano
2018-03-08 12:03 ` Daniel Thompson
2018-03-26 14:30 ` Leo Yan
2018-03-27 9:35 ` Daniel Lezcano
[not found] ` <1519226968-19821-7-git-send-email-daniel.lezcano@linaro.org>
[not found] ` <20180223073432.GF26947@vireshk-i7>
[not found] ` <faaf027c-e01c-6801-9a0c-ab7e0ba669a1@linaro.org>
2018-02-26 4:30 ` [PATCH V2 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver Viresh Kumar
2018-03-13 19:15 ` Daniel Lezcano
2018-04-04 8:50 ` Daniel Lezcano
2018-04-05 4:49 ` Viresh Kumar
2018-03-27 3:43 ` Leo Yan
2018-03-27 11:10 ` Daniel Lezcano
2018-03-27 2:03 ` Leo Yan
2018-03-27 10:26 ` Daniel Lezcano
2018-03-27 12:28 ` Juri Lelli
2018-03-27 12:31 ` Daniel Lezcano
2018-03-27 13:08 ` Juri Lelli
2018-03-27 3:35 ` Leo Yan
2018-03-27 10:56 ` Daniel Lezcano
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=20180308085949.GB17761@amd \
--to=pavel@ucw.cz \
--cc=amit.kachhap@gmail.com \
--cc=corbet@lwn.net \
--cc=daniel.lezcano@linaro.org \
--cc=daniel.thompson@linaro.org \
--cc=edubezval@gmail.com \
--cc=javi.merino@kernel.org \
--cc=kevin.wangtao@linaro.org \
--cc=leo.yan@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rui.zhang@intel.com \
--cc=vincent.guittot@linaro.org \
/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).