From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 05/16] PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe
Date: Tue, 4 Jun 2019 16:05:31 +0300 [thread overview]
Message-ID: <71f7b41c-b33f-92fa-e0a5-85fefeb57274@gmail.com> (raw)
In-Reply-To: <20190604110042.GE16519@ulmo>
04.06.2019 14:00, Thierry Reding пишет:
> On Thu, May 02, 2019 at 02:38:04AM +0300, Dmitry Osipenko wrote:
>> There is no real benefit from doing so, hence let's drop that rate setting
>> for consistency.
>>
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> drivers/devfreq/tegra-devfreq.c | 2 --
>> 1 file changed, 2 deletions(-)
>
> Do you have any numbers to tell how long it would take for the EMC rate
> to get incremented? My understanding is that ACTMON basically reacts to
> system load, so I could imagine that not setting to the maximum
> frequency after this is loaded might make the system slow in the short
> term. Only after ACTMON has collected enough data to determine that it
> needs to clock the EMC higher would system speed resume normal.
>
> I guess technically this patch doesn't change anything if the system
> already boots at the highest EMC frequency anyway, which I think it does
> on many (although not all) devices.
>
> Anyway, you said you've tested this and are satisfied with the
> performance, so it can't be that bad:
>
> Acked-by: Thierry Reding <treding@nvidia.com>
It takes 12ms for ACTMON to react and then about (couple) hundred
microseconds to change memory freq. This is a very short period of time
that human being can't notice.
AFAIK, in practice there are no devices in the wild that boot up with
DRAM clocked at lowest rate. Most devices have a video output and thus
require significant memory bandwidth at a boot time already. Secondly,
higher memory bandwidth is only really needed for a cases like
multimedia, in most generic cases CPU is hitting cache and not utilizing
DRAM a lot.
next prev parent reply other threads:[~2019-06-04 13:05 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190501234148epcas5p1cc9a8dafa9ee6d8d046d1292b8270727@epcas5p1.samsung.com>
2019-05-01 23:37 ` [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support Dmitry Osipenko
2019-05-01 23:37 ` Dmitry Osipenko
2019-05-01 23:38 ` [PATCH v4 01/16] PM / devfreq: tegra: Fix kHz to Hz conversion Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 10:54 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 02/16] PM / devfreq: tegra: Replace readl-writel with relaxed versions Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 10:55 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 03/16] PM / devfreq: tegra: Replace write memory barrier with the read barrier Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 10:56 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 04/16] PM / devfreq: tegra: Don't ignore clk errors Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 10:57 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 05/16] PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:00 ` Thierry Reding
2019-06-04 13:05 ` Dmitry Osipenko [this message]
2019-05-01 23:38 ` [PATCH v4 06/16] PM / devfreq: tegra: Drop primary interrupt handler Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:02 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 07/16] PM / devfreq: tegra: Properly disable interrupts Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:07 ` Thierry Reding
2019-06-04 13:40 ` Dmitry Osipenko
2019-06-04 14:06 ` Thierry Reding
2019-06-04 14:59 ` Dmitry Osipenko
2019-06-04 22:55 ` Dmitry Osipenko
2019-06-07 16:58 ` Dmitry Osipenko
2019-05-01 23:38 ` [PATCH v4 08/16] PM / devfreq: tegra: Clean up driver's probe / remove Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:09 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 09/16] PM / devfreq: tegra: Avoid inconsistency of current frequency value Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:14 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 10/16] PM / devfreq: tegra: Mark ACTMON's governor as immutable Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:15 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 11/16] PM / devfreq: tegra: Move governor registration to driver's probe Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:15 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 12/16] PM / devfreq: tegra: Reconfigure hardware on governor's restart Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:17 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30 Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:18 ` Thierry Reding
2019-05-01 23:38 ` [PATCH v4 14/16] PM / devfreq: tegra: Enable COMPILE_TEST for the driver Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:20 ` Thierry Reding
2019-06-04 13:53 ` Dmitry Osipenko
2019-06-04 14:10 ` Thierry Reding
2019-06-04 14:18 ` Thierry Reding
2019-06-04 14:41 ` Dmitry Osipenko
2019-06-04 14:50 ` Thierry Reding
2019-06-04 15:15 ` Dmitry Osipenko
2019-05-01 23:38 ` [PATCH v4 15/16] PM / devfreq: tegra: Rename tegra-devfreq.c to tegra30-devfreq.c Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:23 ` Thierry Reding
2019-06-04 14:35 ` Dmitry Osipenko
2019-05-01 23:38 ` [PATCH v4 16/16] PM / devfreq: Introduce driver for NVIDIA Tegra20 Dmitry Osipenko
2019-05-01 23:38 ` Dmitry Osipenko
2019-06-04 11:25 ` Thierry Reding
2019-06-04 13:57 ` Dmitry Osipenko
2019-05-03 0:31 ` [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support Chanwoo Choi
2019-05-03 0:31 ` Chanwoo Choi
2019-05-03 0:52 ` Dmitry Osipenko
2019-05-03 0:52 ` Dmitry Osipenko
2019-06-03 16:52 ` Dmitry Osipenko
2019-06-04 0:49 ` Chanwoo Choi
2019-06-04 23:09 ` Dmitry Osipenko
2019-06-23 17:17 ` Dmitry Osipenko
2019-06-23 23:50 ` Chanwoo Choi
2019-06-24 0:35 ` Dmitry Osipenko
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=71f7b41c-b33f-92fa-e0a5-85fefeb57274@gmail.com \
--to=digetx@gmail.com \
--cc=cw00.choi@samsung.com \
--cc=jonathanh@nvidia.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=thierry.reding@gmail.com \
--cc=tomeu.vizoso@collabora.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).