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: <56A0D12A.1080007@linaro.org>
Date:	Thu, 21 Jan 2016 13:38:02 +0100
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>, 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 11:08 AM, Peter Zijlstra wrote:
> On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
>
>> 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.
>>
>> IMO, the handler is at the right place. The prediction code does not take
>> care of the shared interrupts yet.
>
> That certainly added to the confusion. But if you want per dev_id stats,
> the whole alloc framework is 'broken' too, for it allocates the stuff
> per irq.

Yep, that's correct. I was planning to re-work it later by handling the 
shared interrupts, assuming they were not so common, but regarding the 
examples below, that's wrong.

>> 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 ?
>
> They're less common (thankfully) than they used to be, but I still have
> them:
>
> root@...-ep:~# cat /proc/interrupts | grep ","
>    59:          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0   IO-APIC
>    5-fasteoi   i801_smbus, i801_smbus
>
> root@...-ep:~# cat /proc/interrupts | grep ","
>   18:          0          0          0          0          0          0          0          0          0          0          0          0   IO-APIC  18-fasteoi   ehci_hcd:usb1, uhci_hcd:usb6
>   19:    9695230   19577242   13205011    3970578     740376    1138693          0          0          0          0          0          0   IO-APIC  19-fasteoi   uhci_hcd:usb5, ata_piix
>   23:          3          0          0          0        927          0          0          0          0          0          0          0   IO-APIC  23-fasteoi   ehci_hcd:usb2, uhci_hcd:usb4
>
> root@snb:~# cat /proc/interrupts | grep ","
>   19:   11058485          0          0          0          0          0          0          0   IO-APIC  19-fasteoi   ata_piix, ata_piix
>
>
> Also there's a whole host of SOCs that has them.

Ah, I see. Thank you very much for these examples.

Sounds like, I have to handle the shared interrupts sooner than what I 
was expecting ... :)

   -- Daniel



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