linux-kernel - Re: [PATCH 0/4] time: dynamic irq affinity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Mar 2013 14:42:41 +0530
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>
CC:	<john.stultz@...aro.org>, <tglx@...utronix.de>,
	<viresh.kumar@...aro.org>, <jacob.jun.pan@...ux.intel.com>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-pm@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linaro-kernel@...ts.linaro.org>,
	<patches@...aro.org>, <linus.walleij@...ricsson.com>
Subject: Re: [PATCH 0/4] time: dynamic irq affinity

On Monday 11 March 2013 02:10 PM, Daniel Lezcano wrote:
> 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 most likely it will be limited to peripheral interrupts. SGI's
are per-cpu irq's so you need to check that part.

> 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.
> 
Good.

> 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.
> 
It isn't straight forward. The easiest way is to replace the SGI IPI
with one which is wakeup capable even from deeper states. But then
it all depends on hardware support and what that hook looks
like per platform.

Regards,
Santosh


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/