linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	rafael@kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, nicolas.pitre@linaro.org,
	vincent.guittot@linaro.org
Subject: Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings
Date: Thu, 21 Jan 2016 13:38:02 +0100	[thread overview]
Message-ID: <56A0D12A.1080007@linaro.org> (raw)
In-Reply-To: <20160121100834.GM6356@twins.programming.kicks-ass.net>

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@ivb-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@wsm-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


  reply	other threads:[~2016-01-21 12:38 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 15:22 [RFC PATCH 0/2] IRQ based next prediction Daniel Lezcano
2016-01-06 15:22 ` [RFC PATCH 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-08 15:31   ` Thomas Gleixner
2016-01-12 11:42     ` Daniel Lezcano
2016-01-06 15:22 ` [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-06 17:40   ` Nicolas Pitre
2016-01-07 15:42     ` Daniel Lezcano
2016-01-12 19:27       ` Nicolas Pitre
2016-01-10 22:37     ` Daniel Lezcano
2016-01-10 22:46       ` Nicolas Pitre
2016-01-10 22:58         ` Daniel Lezcano
2016-01-10 23:13           ` Nicolas Pitre
2016-01-08 15:43   ` Thomas Gleixner
2016-01-12 12:41     ` Daniel Lezcano
2016-01-12 13:42       ` Thomas Gleixner
2016-01-12 14:16         ` Daniel Lezcano
2016-01-12 14:26           ` Thomas Gleixner
2016-01-12 14:52             ` Daniel Lezcano
2016-01-12 15:12               ` Thomas Gleixner
2016-01-12 16:04                 ` Daniel Lezcano
2016-01-13  9:17                   ` Thomas Gleixner
2016-01-18 13:21     ` Daniel Lezcano
2016-01-20 15:41       ` Thomas Gleixner
2016-01-20 16:00         ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 17:55             ` Thomas Gleixner
2016-01-21  9:25               ` Daniel Lezcano
2016-01-21 10:27                 ` Thomas Gleixner
2016-01-20 19:07             ` Peter Zijlstra
2016-01-20 19:57               ` Thomas Gleixner
2016-01-20 20:04                 ` Nicolas Pitre
2016-01-20 20:20                 ` Peter Zijlstra
2016-01-20 20:22                   ` Thomas Gleixner
2016-01-21  9:50                 ` Daniel Lezcano
2016-01-21 10:08                   ` Peter Zijlstra
2016-01-21 12:38                     ` Daniel Lezcano [this message]
2016-01-21 20:27                     ` Thomas Gleixner
2016-01-21 13:52                   ` Thomas Gleixner
2016-01-21 14:19                     ` Daniel Lezcano
2016-01-21 18:56                       ` Thomas Gleixner
2016-01-22 10:15                         ` Peter Zijlstra
2016-01-21  9:26               ` Daniel Lezcano
2016-01-20 19:28             ` Peter Zijlstra
2016-01-21  9:53               ` Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 17:46             ` Nicolas Pitre
2016-01-20 18:44               ` Peter Zijlstra
2016-01-21 10:03               ` Daniel Lezcano
2016-01-20 19:02             ` Peter Zijlstra
2016-01-20 19:17               ` Nicolas Pitre
2016-01-20 19:29                 ` Peter Zijlstra
2016-01-20 19:34             ` Peter Zijlstra
2016-01-20 19:40             ` Peter Zijlstra
2016-01-20 19:57               ` Nicolas Pitre
2016-01-20 20:22                 ` Peter Zijlstra
2016-01-20 19:49             ` Thomas Gleixner
2016-01-21 13:54               ` Daniel Lezcano
2016-01-21 14:12                 ` Thomas Gleixner
2016-01-20 16:00           ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 16:00           ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 20:14             ` Nicolas Pitre
2016-01-21 13:04               ` Daniel Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A0D12A.1080007@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).