linux-kernel - Re: [PATCH V4] 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]

Date:	Tue, 14 Jun 2016 17:38:46 +0200
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>, shreyas@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	rafael@...nel.org, vincent.guittot@...aro.org
Subject: Re: [PATCH V4] irq: Track the interrupt timings

On 06/14/2016 05:10 PM, Nicolas Pitre wrote:
> On Tue, 14 Jun 2016, Daniel Lezcano wrote:
>
>> On 06/10/2016 04:52 PM, Thomas Gleixner wrote:
>>
>>>> +	timings->sum -= timings->values[timings->w_index];
>>>> +	timings->values[timings->w_index] = diff;
>>>> +	timings->sum += diff;
>>>
>>> Now the real question is whether you really need all that math, checks and
>>> memsets in the irq hotpath. If you make the storage slightly larger then you
>>> can just store the values unconditionally in the circular buffer and do all
>>> the computational stuff when you really it.
>>
>> Yes, that was one concern when I wrote the code: do some basic computation
>> when an interrupt occurs, and the rest after or do the entire math when
>> entering idle.
>>
>> If the storage is a bit larger (let's say 16 values) and there is no memset
>> and the sum is not computed, at least we need a count for the number of values
>> in the array before this one is fulfilled, otherwise the statistics will be
>> wrong as we will take into account the entire array with old values, no ?
>
> The point is not to change from 8 to 16 entries, but to store raw 64-bit
> timestamps instead of computed 32-bit deltas.  Whether or not those
> timestamps are too far apart and discarded can be done at idle entry
> time.

Ah, ok. That makes sense.

Thanks for the clarification.

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