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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.11.1601211128240.3873@nanos>
Date:	Thu, 21 Jan 2016 14:52:31 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>
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 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.

Thanks,

	tglx