Thread (22 messages) 22 messages, 6 authors, 2021-06-16

Re: [PATCH v3 4/7] thermal/drivers/tegra: Add driver for Tegra30 thermal sensor

From: Dmitry Osipenko <digetx@gmail.com>
Date: 2021-06-16 10:49:26
Also in: linux-pm, linux-tegra, lkml

16.06.2021 11:51, Vincent Guittot пишет:
On Wed, 16 Jun 2021 at 10:39, Dmitry Osipenko [off-list ref] wrote:
quoted
16.06.2021 11:30, Vincent Guittot пишет:
quoted
On Wed, 16 Jun 2021 at 10:03, Viresh Kumar [off-list ref] wrote:
quoted
+Vincent.

On 15-06-21, 22:32, Dmitry Osipenko wrote:
quoted
IIUC, the cpufreq already should be prepared for the case where firmware
may override frequency. Viresh, could you please clarify what are the
possible implications of the frequency overriding?
The only implication is software would think hardware is running at
some other frequency, while it is not. Not sure if something may break
as a result of this.

The scheduler's view of CPUs will not be same though, i.e. scheduler
will see capacity as X, while in reality it has changed to Y.
thermal_pressure is used by scheduler to balance the load between CPUs
according to the actual max frequency. If the thermal pressure doesn't
reflect reality, scheduler will end up enqueuing too many  tasks on a
throttle CPU.
What if all CPUs are throttled equally and running on the same
frequency, will throttling have any effect on the scheduler decisions?
Yes, the capacity is also used to detect when CPUs have spare capacity
or are already overloaded. We usually try to fill the spare capacity
of a CPU (CPU's max capacity - current utilization) but he max
capacity is reduced when the CPU is throttled, and the spare capacity
doesn't exist but scheduler could try to it
Thank you.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help