From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
shreyas@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
peterz@infradead.org, rafael@kernel.org,
vincent.guittot@linaro.org
Subject: Re: [PATCH V4] irq: Track the interrupt timings
Date: Tue, 14 Jun 2016 17:38:46 +0200 [thread overview]
Message-ID: <57602506.1020007@linaro.org> (raw)
In-Reply-To: <alpine.LFD.2.20.1606141105320.1714@knanqh.ubzr>
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
next prev parent reply other threads:[~2016-06-14 15:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-13 11:05 [PATCH V4] irq: Track the interrupt timings Daniel Lezcano
2016-04-22 18:21 ` Daniel Lezcano
2016-05-03 13:44 ` Daniel Lezcano
2016-06-10 14:52 ` Thomas Gleixner
2016-06-10 15:11 ` Nicolas Pitre
2016-06-10 15:20 ` Thomas Gleixner
2016-06-10 15:29 ` Nicolas Pitre
2016-06-14 13:36 ` Daniel Lezcano
2016-06-14 15:10 ` Nicolas Pitre
2016-06-14 15:38 ` Daniel Lezcano [this message]
2016-06-14 16:36 ` Thomas Gleixner
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=57602506.1020007@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=shreyas@linux.vnet.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.