From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: john.stultz@linaro.org, tglx@linutronix.de,
viresh.kumar@linaro.org, jacob.jun.pan@linux.intel.com,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org,
patches@linaro.org, linus.walleij@stericsson.com
Subject: Re: [PATCH 0/4] time: dynamic irq affinity
Date: Mon, 11 Mar 2013 09:40:54 +0100 [thread overview]
Message-ID: <513D9896.2010304@linaro.org> (raw)
In-Reply-To: <513D4E79.5090307@ti.com>
On 03/11/2013 04:24 AM, Santosh Shilimkar wrote:
> On Sunday 10 March 2013 11:52 PM, Daniel Lezcano wrote:
[ ... ]
>> I don't think it is the case for all the ARM platforms, at least we
>> tested it on vexpress TC2 and u8500, and the number of IPI were reduced
>> very significantly increasing the idle time for cpu0. TC2 will need
>> another optimization on another area for the idle wake up to gain real
>> improvements.
>>
> You are missing my point. TC2 can be an exception since the SGI can wakeup
> CPUs even from low power states where local timer's are stalled. Is that
> the case with U8500 ?
Well, the cpuidle driver is not going into a deep idle state to check
this out.
AFAICT this board has a specific firmware with the PRCMU (a device
managing the power on the board) and it replaces the GIC when going to
deep idle state, especially by reconnecting the GIC to the A9 cores
automatically when an interrupt occurs.
But definitively worth to check.
>> I will test it on OMAP but with the coupled idle state, I am not sure of
>> the behavior. Could elaborate a bit the specificity of OMAP ? I am not
>> sure to understand why I may miss some IPI wakeups.
>>
> I already mention the issue here [1]. You might not see any major issues
> because the missed asynchronous IPIs might eventually get executed when
> CPU's wakeup from deeper states because of idle wakeups. OMAP is no
> different from idle wakeup optimisation and it will surely benefit and work.
> The main reason I didn't pursue it because of not having solution for
> [1] which as discussed in past is very much essential from kernel
> functional correctness perspective. You might want to verify that by
> adding a tracepoint on IPI's on other reasons except the timer wakeup.
Oh, ok. I didn't make the connection. I got the point now.
If we can raise a fake hardware interrupt on the GIC (not sure that
could be done), may be we can implement something similar to the
broadcast timer mechanism to replace the IPI when the cores are not IPI
wakeup capable.
> [1] https://lkml.org/lkml/2013/2/27/39
>
--
<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-03-11 8:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-26 22:17 [PATCH 0/4] time: dynamic irq affinity Daniel Lezcano
2013-02-26 22:17 ` [PATCH 1/4] time : pass broadcast parameter Daniel Lezcano
2013-02-27 5:09 ` Santosh Shilimkar
2013-02-26 22:17 ` [PATCH 2/4] time : set broadcast irq affinity Daniel Lezcano
2013-02-27 5:33 ` Santosh Shilimkar
2013-02-26 22:17 ` [PATCH 3/4] ARM: nomadik: add dynamic irq flag to the timer Daniel Lezcano
2013-03-01 1:13 ` Linus Walleij
2013-03-01 8:56 ` Vincent Guittot
2013-03-01 13:28 ` Rickard Andersson
2013-02-26 22:17 ` [PATCH 4/4] ARM: timer-sp: Set dynamic irq affinity Daniel Lezcano
2013-02-27 4:56 ` Santosh Shilimkar
2013-02-27 4:59 ` Viresh Kumar
2013-02-27 5:04 ` Santosh Shilimkar
2013-02-27 6:00 ` [PATCH 0/4] time: " Santosh Shilimkar
2013-02-27 10:47 ` Russell King - ARM Linux
2013-02-27 22:00 ` Thomas Gleixner
2013-03-10 17:33 ` Santosh Shilimkar
2013-03-10 18:22 ` Daniel Lezcano
2013-03-11 3:24 ` Santosh Shilimkar
2013-03-11 8:40 ` Daniel Lezcano [this message]
2013-03-11 9:12 ` Santosh Shilimkar
2013-03-11 9:28 ` Rickard Andersson
2013-03-11 10:29 ` Santosh Shilimkar
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=513D9896.2010304@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=john.stultz@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=patches@linaro.org \
--cc=santosh.shilimkar@ti.com \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@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).