From: Dmitry Osipenko <digetx@gmail.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Peter De Schrijver" <pdeschrijver@nvidia.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
"Jasper Korten" <jja2000@gmail.com>,
"David Heidelberg" <david@ixit.cz>,
"Peter Geis" <pgwipeout@gmail.com>,
linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 09/17] arm: tegra20: cpuidle: Handle case where secondary CPU hangs on entering LP2
Date: Fri, 21 Feb 2020 23:42:18 +0300 [thread overview]
Message-ID: <e5f25dc2-f96f-0108-e02f-0b0d32da3053@gmail.com> (raw)
In-Reply-To: <50a8fb7c-f497-2234-c0b0-560aec1c5691@gmail.com>
21.02.2020 23:21, Dmitry Osipenko пишет:
> 21.02.2020 23:02, Daniel Lezcano пишет:
>> On 21/02/2020 19:19, Dmitry Osipenko wrote:
>>> 21.02.2020 20:36, Daniel Lezcano пишет:
>>>> On Fri, Feb 21, 2020 at 07:56:51PM +0300, Dmitry Osipenko wrote:
>>>>> Hello Daniel,
>>>>>
>>>>> 21.02.2020 18:43, Daniel Lezcano пишет:
>>>>>> On Thu, Feb 13, 2020 at 02:51:26AM +0300, Dmitry Osipenko wrote:
>>>>>>> It is possible that something may go wrong with the secondary CPU, in that
>>>>>>> case it is much nicer to get a dump of the flow-controller state before
>>>>>>> hanging machine.
>>>>>>>
>>>>>>> Acked-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>>>>> Tested-by: Peter Geis <pgwipeout@gmail.com>
>>>>>>> Tested-by: Jasper Korten <jja2000@gmail.com>
>>>>>>> Tested-by: David Heidelberg <david@ixit.cz>
>>>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>>>>> ---
>>>>
>>>> [ ... ]
>>>>
>>>>>>> +static int tegra20_wait_for_secondary_cpu_parking(void)
>>>>>>> +{
>>>>>>> + unsigned int retries = 3;
>>>>>>> +
>>>>>>> + while (retries--) {
>>>>>>> + ktime_t timeout = ktime_add_ms(ktime_get(), 500);
>>>>>>
>>>>>> Oops I missed this one. Do not use ktime_get() in this code path, use jiffies.
>>>>>
>>>>> Could you please explain what benefits jiffies have over the ktime_get()?
>>>>
>>>> ktime_get() is very slow, jiffies is updated every tick.
>>>
>>> But how jiffies are supposed to be updated if interrupts are disabled?
>>
>> Yeah, other cpus must not be idle in this.
>
> Okay, then jiffies can't be used here because this function is used for
> the coupled / power-gated state only. All CPUs are idling in this state.
>
>>> Aren't jiffies actually slower than ktime_get() because jiffies are
>>> updating every 10/1ms (depending on CONFIG_HZ)?
>>
>> They are no slower, they have a lower resolution which is 10ms or 4ms.
>>
>> Given the 500ms timeout, it is fine.
>>
>>> We're kinda interesting here in getting into deep-idling state as quick
>>> as possible. I was checking how much time takes the busy-loop below and
>>> it takes ~40-150us in average, which is good enough.
>>
>> ktime_get() gets a seq lock and it is very slow.
>
> Since all CPUs are idling here, the locking isn't a problem.
>
> The wait_for_secondary_cpu_parking() function is called on CPU0, it
> waits for the secondary CPUs to enter into safe-state before CPU0 could
> power-gate the whole CPU cluster.
>
>>>>>>> +
>>>>>>> + /*
>>>>>>> + * The primary CPU0 core shall wait for the secondaries
>>>>>>> + * shutdown in order to power-off CPU's cluster safely.
>>>>>>> + * The timeout value depends on the current CPU frequency,
>>>>>>> + * it takes about 40-150us in average and over 1000us in
>>>>>>> + * a worst case scenario.
>>>>>>> + */
>>>>>>> + do {
>>>>>>> + if (tegra_cpu_rail_off_ready())
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> + } while (ktime_before(ktime_get(), timeout));
>>>>>>
>>>>>> So this loop will aggresively call tegra_cpu_rail_off_ready() and retry 3
>>>>>> times. The tegra_cpu_rail_off_ready() function can be called thoushand of times
>>>>>> here but the function will hang 1.5s :/
>>>>>>
>>>>>> I suggest something like:
>>>>>>
>>>>>> while (retries--i && !tegra_cpu_rail_off_ready())
>>>>>> udelay(100);
>>>>>>
>>>>>> So <retries> calls to tegra_cpu_rail_off_ready() and 100us x <retries> maximum
>>>>>> impact.
>>>>> But udelay() also results into CPU spinning in a busy-loop, and thus,
>>>>> what's the difference?
>>>>
>>>> busy looping instead of register reads with all the hardware things involved behind.
>>>
>>> Please notice that this code runs only on an older Cortex-A9/A15, which
>>> doesn't support WFE for the delaying, and thus, CPU always busy-loops
>>> inside udelay().
>>>
>>> What about if I'll add cpu_relax() to the loop? Do you think it it could
>>> have any positive effect?
>>
>> I think udelay() has a call to cpu_relax().
>
> Yes, my point is that udelay() doesn't bring much benefit for us here
> because:
>
> 1. we want to enter into power-gated state as quick as possible and
> udelay() just adds an unnecessary delay
>
> 2. udelay() spins in a busy-loop until delay is expired, just like we're
> doing it in this function already
I'll try the udelay()-loop over the weekend and will see if it makes any
real difference, maybe I'm missing something.
If it doesn't make any difference, I'll leave this patch as-is, okay?
next prev parent reply other threads:[~2020-02-21 20:42 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 23:51 [PATCH v9 00/17] Consolidate and improve NVIDIA Tegra CPUIDLE driver(s) Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 01/17] ARM: tegra: Compile sleep-tegra20/30.S unconditionally Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 02/17] ARM: tegra: Add tegra_pm_park_secondary_cpu() Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 03/17] ARM: tegra: Remove pen-locking from cpuidle-tegra20 Dmitry Osipenko
2020-02-21 14:58 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 04/17] ARM: tegra: Change tegra_set_cpu_in_lp2() type to void Dmitry Osipenko
2020-02-21 15:04 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 05/17] ARM: tegra: Propagate error from tegra_idle_lp2_last() Dmitry Osipenko
2020-02-21 15:16 ` Daniel Lezcano
2020-02-21 17:21 ` Dmitry Osipenko
2020-02-21 17:40 ` Daniel Lezcano
2020-02-21 18:42 ` Dmitry Osipenko
2020-02-21 19:16 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 06/17] ARM: tegra: Expose PM functions required for new cpuidle driver Dmitry Osipenko
2020-02-21 15:18 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 07/17] ARM: tegra: Rename some of the newly exposed PM functions Dmitry Osipenko
2020-02-21 15:19 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 08/17] ARM: tegra: Make outer_disable() open-coded Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 09/17] arm: tegra20: cpuidle: Handle case where secondary CPU hangs on entering LP2 Dmitry Osipenko
2020-02-21 14:55 ` Daniel Lezcano
2020-02-21 15:43 ` Daniel Lezcano
2020-02-21 16:56 ` Dmitry Osipenko
2020-02-21 17:36 ` Daniel Lezcano
2020-02-21 18:19 ` Dmitry Osipenko
2020-02-21 20:02 ` Daniel Lezcano
2020-02-21 20:21 ` Dmitry Osipenko
2020-02-21 20:42 ` Dmitry Osipenko [this message]
2020-02-21 20:48 ` Daniel Lezcano
2020-02-21 20:54 ` Dmitry Osipenko
2020-02-21 21:11 ` Daniel Lezcano
2020-02-24 15:12 ` Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 10/17] arm: tegra20: cpuidle: Make abort_flag atomic Dmitry Osipenko
2020-02-21 15:25 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 11/17] arm: tegra20/30: cpuidle: Remove unnecessary memory barrier Dmitry Osipenko
2020-02-21 15:25 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 12/17] cpuidle: Refactor and move out NVIDIA Tegra20 driver into drivers/cpuidle Dmitry Osipenko
2020-02-21 15:44 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 13/17] cpuidle: tegra: Squash Tegra30 driver into the common driver Dmitry Osipenko
2020-02-21 16:29 ` Daniel Lezcano
2020-02-21 16:59 ` Dmitry Osipenko
2020-02-21 17:41 ` Daniel Lezcano
2020-02-21 18:20 ` Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 14/17] cpuidle: tegra: Squash Tegra114 " Dmitry Osipenko
2020-02-12 23:51 ` [PATCH v9 15/17] cpuidle: tegra: Disable CC6 state if LP2 unavailable Dmitry Osipenko
2020-02-21 16:39 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 16/17] ARM: multi_v7_defconfig: Enable Tegra cpuidle driver Dmitry Osipenko
2020-02-21 16:30 ` Daniel Lezcano
2020-02-12 23:51 ` [PATCH v9 17/17] ARM: tegra: Enable Tegra cpuidle driver in tegra_defconfig Dmitry Osipenko
2020-02-21 16:31 ` Daniel Lezcano
2020-02-13 0:38 ` [PATCH v9 00/17] Consolidate and improve NVIDIA Tegra CPUIDLE driver(s) Dmitry Osipenko
2020-02-18 14:56 ` Dmitry Osipenko
2020-02-24 16:44 ` Dmitry Osipenko
-- strict thread matches above, loose matches on Subject: below --
2019-12-18 21:04 Dmitry Osipenko
2019-12-18 21:04 ` [PATCH v9 09/17] arm: tegra20: cpuidle: Handle case where secondary CPU hangs on entering LP2 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=e5f25dc2-f96f-0108-e02f-0b0d32da3053@gmail.com \
--to=digetx@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=david@ixit.cz \
--cc=jja2000@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mirq-linux@rere.qmqm.pl \
--cc=pdeschrijver@nvidia.com \
--cc=pgwipeout@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=thierry.reding@gmail.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).