linux-kernel - Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings

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 for Android: free password hash cracker in your pocket

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

Message-ID: <56A0E8F1.7010409@linaro.org>
Date:	Thu, 21 Jan 2016 15:19:29 +0100
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Peter Zijlstra <peterz@...radead.org>, rafael@...nel.org,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	nicolas.pitre@...aro.org, vincent.guittot@...aro.org
Subject: Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings

On 01/21/2016 02:52 PM, Thomas Gleixner wrote:
> On Thu, 21 Jan 2016, Daniel Lezcano wrote:
>> On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
>>> That and we don't want to call it for each handler which returned handled.
>>> The
>>> called code would do two samples in a row for the same interrupt in case of
>>> two shared handlers which get raised at the same time. Not very likely, but
>>> possible.
>>
>> Actually, the handle passes dev_id in order to let the irqtimings to sort out
>> a shared interrupt and prevent double sampling. In other words, for shared
>> interrupts, statistics should be per t-uple(irq , dev_id) but that is
>> something I did not implemented ATM.
>
> So my comment about double sampling applies.
>
>> IMO, the handler is at the right place. The prediction code does not take care
>> of the shared interrupts yet.
>>
>> I tried to find a platform with shared interrupts in the ones I have available
>> around me but I did not find any. Are the shared interrupts something used
>> nowadays or coming from legacy hardware ? What is the priority to handle the
>> shared interrupts in the prediction code ?
>
> And why would that thing care about shared interruts at all? It's a legacy
> burden and I really don't see a reason why that new thing which is targeted on
> modern hardware should deal with them. Just treat them as a single interrupt
> for now and be done with it.

I just sent an email about how handling them :)

If the shared interrupts are only related to old hardware, these ones 
shouldn't have cpuidle, hence there is no need to enable the irq 
timings. So you are right in this case and we can keep the feature simple.

On a other hand, Peter sent three examples of /proc/interrupts with 
shared interrupts. I don't know how old are the platforms and what are 
they, but it seems the shared irq are still used.

At this point I have two contradictory information.

For the best of my knowledge, I am inclined to agree with you.

Peter can you give your opinion ?

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