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: <56A0A9E3.2070306@linaro.org>
Date:	Thu, 21 Jan 2016 10:50:27 +0100
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Cc:	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/20/2016 08:57 PM, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Peter Zijlstra wrote:
>
>> On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
>>> +++ b/kernel/irq/handle.c
>>> @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
>>>   			/* Fall through to add to randomness */
>>>   		case IRQ_HANDLED:
>>>   			flags |= action->flags;
>>> +			handle_irqtiming(irq, action->dev_id);
>>>   			break;
>>>
>>>   		default:
>>
>>> +++ b/kernel/irq/internals.h
>>
>>> +static inline void handle_irqtiming(unsigned int irq, void *dev_id)
>>> +{
>>> +	if (__irqtimings->handler)
>>> +		__irqtimings->handler(irq, ktime_get(), dev_id);
>>> +}
>>
>> Here too, ktime_get() is daft.
>
> What's the problem? ktime_xxx() itself or just the clock monotonic variant?
>
> On 99.9999% of the platforms ktime_get_mono_fast/raw_fast is not any slower
> than sched_clock(). The only case where sched_clock is faster is if your TSC
> is buggered and the box switches to HPET for timekeeping.
>
> But I wonder, whether this couldn't do with jiffies in the first place. If the
> interrupt comes faster than a jiffie then you hardly go into some interesting
> power state, but I might be wrong as usual :)
>
>> Also, you really want to take the timestamp _before_ we call the
>> handlers, not after, otherwise you mix in whatever variance exist in the
>> handler duration.
>
> 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.

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 ?



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