From: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Joseph Lo <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
Date: Wed, 17 Jul 2013 12:21:18 +0200 [thread overview]
Message-ID: <51E6701E.2070909@linaro.org> (raw)
In-Reply-To: <1374056130.10997.16.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
On 07/17/2013 12:15 PM, Joseph Lo wrote:
> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>> this state.
>>> or something can increase
>>> the loading or make regressions. But I think you are testing with USB
>>> device attached, right? That might cause some extra loading. You can
>>> give it a try after just removing USB device. And I double confirm that
>>> on Seaboard. Except that, the test result looks OK for me.
>>
>> Yes, having a USB device plugged in does affect the issue. In summary:
>>
>> next-20130716, with or without USB devices plugged in: Works fine.
>>
>> next-20130716 with your patches, without USB device plugged in:
>> Occasional short problems (detailed below).
>>
>> next-20130716 with your patches, with USB device plugged in: Continual
>> long problems (detailed below).
>>
>> The testing I did was to log in over the serial console, hit <enter>
>> around five times, and watch the shell prompt echo back, then type
>> "ls<enter" and watch the (directory listing appear (I have about 20
>> files in my directory, with long-ish names), then repeat. With plain
>> next-20130716, this is nice and fast and there are no pauses. With your
>> patches applied, there are occasional or continual pauses, which last
>> for either a short time (tenths of a second), or even a second or two,
>> both depending on whether a USB device is plugged in or not.
>>
>> I believe this is the same issue I saw when I applied your patches to
>> the Tegra tree on top of v3.11-rc1.
>>
> OK. I did more stress tests last night and today. I found it cause by
> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> only impact the Tegra20 platform. The hot plug regression seems due to
> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> can back to normal.
>
> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>
> Can the other two patch series for Tegra114 to support CPU idle power
> down mode and system suspend still moving forward, not be blocked by
> this patch?
>
> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> hot plug on Tegra20, I will continue to check this. You can just drop
> this patch.
Please in the future Cc me when problems occur with some patches I
submitted. That would be easier for me to track the issues and fix them
when they happen.
Thanks
-- Daniel
--
<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
WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag
Date: Wed, 17 Jul 2013 12:21:18 +0200 [thread overview]
Message-ID: <51E6701E.2070909@linaro.org> (raw)
In-Reply-To: <1374056130.10997.16.camel@jlo-ubuntu-64.nvidia.com>
On 07/17/2013 12:15 PM, Joseph Lo wrote:
> On Wed, 2013-07-17 at 03:51 +0800, Stephen Warren wrote:
>> On 07/16/2013 05:17 AM, Joseph Lo wrote:
>>> On Tue, 2013-07-16 at 02:04 +0800, Stephen Warren wrote:
>>>> On 06/25/2013 03:23 AM, Joseph Lo wrote:
>>>>> Use the CPUIDLE_FLAG_TIMER_STOP and let the cpuidle framework
>>>>> to handle the CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT when entering
>>>>> this state.
>>> or something can increase
>>> the loading or make regressions. But I think you are testing with USB
>>> device attached, right? That might cause some extra loading. You can
>>> give it a try after just removing USB device. And I double confirm that
>>> on Seaboard. Except that, the test result looks OK for me.
>>
>> Yes, having a USB device plugged in does affect the issue. In summary:
>>
>> next-20130716, with or without USB devices plugged in: Works fine.
>>
>> next-20130716 with your patches, without USB device plugged in:
>> Occasional short problems (detailed below).
>>
>> next-20130716 with your patches, with USB device plugged in: Continual
>> long problems (detailed below).
>>
>> The testing I did was to log in over the serial console, hit <enter>
>> around five times, and watch the shell prompt echo back, then type
>> "ls<enter" and watch the (directory listing appear (I have about 20
>> files in my directory, with long-ish names), then repeat. With plain
>> next-20130716, this is nice and fast and there are no pauses. With your
>> patches applied, there are occasional or continual pauses, which last
>> for either a short time (tenths of a second), or even a second or two,
>> both depending on whether a USB device is plugged in or not.
>>
>> I believe this is the same issue I saw when I applied your patches to
>> the Tegra tree on top of v3.11-rc1.
>>
> OK. I did more stress tests last night and today. I found it cause by
> the patch "ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag" and
> only impact the Tegra20 platform. The hot plug regression seems due to
> this patch. After dropping this patch on top of v3.11-rc1, the Tegra20
> can back to normal.
>
> And the hop plug and suspend stress test can pass on Tegra30/114 too.
>
> Can the other two patch series for Tegra114 to support CPU idle power
> down mode and system suspend still moving forward, not be blocked by
> this patch?
>
> Looks the CPUIDLE_FLAG_TIMER_STOP flag still cause some other issue for
> hot plug on Tegra20, I will continue to check this. You can just drop
> this patch.
Please in the future Cc me when problems occur with some patches I
submitted. That would be easier for me to track the issues and fix them
when they happen.
Thanks
-- Daniel
--
<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
next prev parent reply other threads:[~2013-07-17 10:21 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 9:23 [PATCH] ARM: tegra: cpuidle: use CPUIDLE_FLAG_TIMER_STOP flag Joseph Lo
2013-06-25 9:23 ` Joseph Lo
[not found] ` <1372152228-16199-1-git-send-email-josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-06-25 15:12 ` Stephen Warren
2013-06-25 15:12 ` Stephen Warren
[not found] ` <51C9B36A.3040808-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-26 11:11 ` Joseph Lo
2013-06-26 11:11 ` Joseph Lo
2013-07-15 18:04 ` Stephen Warren
2013-07-15 18:04 ` Stephen Warren
[not found] ` <51E439BC.9030608-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-16 10:19 ` Peter De Schrijver
2013-07-16 10:19 ` Peter De Schrijver
2013-07-16 11:17 ` Joseph Lo
2013-07-16 11:17 ` Joseph Lo
[not found] ` <1373973447.8538.80.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-16 12:11 ` Daniel Lezcano
2013-07-16 12:11 ` Daniel Lezcano
[not found] ` <51E53858.6090207-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-07-17 6:19 ` Joseph Lo
2013-07-17 6:19 ` Joseph Lo
2013-07-16 19:51 ` Stephen Warren
2013-07-16 19:51 ` Stephen Warren
[not found] ` <51E5A438.10004-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-17 10:15 ` Joseph Lo
2013-07-17 10:15 ` Joseph Lo
[not found] ` <1374056130.10997.16.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-17 10:21 ` Daniel Lezcano [this message]
2013-07-17 10:21 ` Daniel Lezcano
[not found] ` <51E6701E.2070909-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-07-17 10:29 ` Joseph Lo
2013-07-17 10:29 ` Joseph Lo
2013-07-17 20:31 ` Stephen Warren
2013-07-17 20:31 ` Stephen Warren
[not found] ` <51E6FF0B.5000708-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-17 21:45 ` Daniel Lezcano
2013-07-17 21:45 ` Daniel Lezcano
[not found] ` <51E7108B.5030504-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-07-17 22:01 ` Stephen Warren
2013-07-17 22:01 ` Stephen Warren
2013-07-18 11:08 ` Joseph Lo
2013-07-18 11:08 ` Joseph Lo
[not found] ` <1374145726.5610.73.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-18 12:41 ` Daniel Lezcano
2013-07-18 12:41 ` Daniel Lezcano
[not found] ` <51E7E27B.9090605-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-07-19 7:14 ` Joseph Lo
2013-07-19 7:14 ` Joseph Lo
[not found] ` <1374218064.24607.1.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-19 10:52 ` Daniel Lezcano
2013-07-19 10:52 ` Daniel Lezcano
2013-07-22 3:15 ` Joseph Lo
2013-07-22 3:15 ` Joseph Lo
[not found] ` <1374462916.15946.14.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-22 4:16 ` Daniel Lezcano
2013-07-22 4:16 ` Daniel Lezcano
[not found] ` <51ECB223.5000002-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-07-22 4:24 ` Joseph Lo
2013-07-22 4:24 ` Joseph Lo
[not found] ` <1374467085.15946.16.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-22 4:32 ` Daniel Lezcano
2013-07-22 4:32 ` Daniel Lezcano
[not found] ` <51ECB5C1.600-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-07-22 4:43 ` Joseph Lo
2013-07-22 4:43 ` Joseph Lo
[not found] ` <1374468208.15946.17.camel-yx3yKKdKkHfc7b1ADBJPm0n48jw8i0AO@public.gmane.org>
2013-07-22 4:44 ` Daniel Lezcano
2013-07-22 4:44 ` Daniel Lezcano
2013-07-19 9:29 ` Joseph Lo
2013-07-19 9:29 ` Joseph Lo
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=51E6701E.2070909@linaro.org \
--to=daniel.lezcano-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.