linux-kernel - Re: [PATCH V7] irq: Track the 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.1606231037380.5839@nanos>
Date:	Thu, 23 Jun 2016 10:41:57 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>
cc:	nicolas.pitre@...aro.org, shreyas@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	rafael@...nel.org, vincent.guittot@...aro.org
Subject: Re: [PATCH V7] irq: Track the interrupt timings

On Fri, 17 Jun 2016, Daniel Lezcano wrote:
> The interrupt framework gives a lot of information about each interrupt.
> 
> It does not keep track of when those interrupts occur though.
> 
> This patch provides a mean to record the elapsed time between successive
> interrupt occurrences in a per-IRQ per-CPU circular buffer to help with the
> prediction of the next occurrence using a statistical model.
> 
> A new function is added to browse the different interrupts and retrieve the
> timing information stored in it.
> 
> A static key is introduced so when the irq prediction is switched off at
> runtime, we can reduce the overhead near to zero. The irq timings is
> supposed to be potentially used by different sub-systems and for this reason
> the static key is a ref counter, so when the last use releases the irq
> timings that will result on the effective deactivation of the irq measurement.

Before merging this I really have to ask a few more questions. I'm a bit
worried about the usage site of this. It's going to iterate over all
interrupts in the system to do a next interrupt prediction. On larger machines
that's going to be quite some work and you touch a gazillion of cache lines
and many of them just to figure out that nothing happened.

Is it really required to do this per interrupt rather than providing per cpu
statistics of interrupts which arrived in the last X seconds or whatever
timeframe is relevant for this.

Thanks,

	tglx