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.1601212114480.3886@nanos>
Date:	Thu, 21 Jan 2016 21:27:11 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Daniel Lezcano <daniel.lezcano@...aro.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, 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.
> 
> > 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 ","
>   0   IO-APIC  5-fasteoi   i801_smbus, i801_smbus

Hardly something which is worth to add the extra complexity.
 
> root@...-ep:~# cat /proc/interrupts | grep ","
>  18:  0   0	 IO-APIC  18-fasteoi   ehci_hcd:usb1, uhci_hcd:usb6
>  23:  3   927  IO-APIC  23-fasteoi   ehci_hcd:usb2, uhci_hcd:usb4

Stick the USB thingy into the XHCI port :)

>  19:    9695230   19577242  .... IO-APIC  19-fasteoi   uhci_hcd:usb5, ata_piix
> root@snb:~# cat /proc/interrupts | grep ","
>  19:   11058485   IO-APIC  19-fasteoi   ata_piix, ata_piix

Go to the BIOS and enable AHCI mode. Both the snb and the wsm-ep chipsets can
be switched between legacy piix and ahci mode :)

You seem to have a faible for last century hardware.

> Also there's a whole host of SOCs that has them.

And one of the reasons is, that a lot of drivers do not support msi, while
these embedded beasts support MSI on almost every peripheral, at least the
newer ones.

Thanks,

	tglx