linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: nicolas.pitre@linaro.org, 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 15:36:38 +0200	[thread overview]
Message-ID: <57600866.4070601@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.11.1606101625320.5839@nanos>

On 06/10/2016 04:52 PM, Thomas Gleixner wrote:

Hi Thomas,

[ ... ]

>> +	now = local_clock();
>> +	prev = timings->timestamp;
>> +	timings->timestamp = now;
>> +
>> +	/*
>> +	 * If it is the first interrupt of the series, we can't
>> +	 * compute an interval, just store the timestamp and exit.
>> +	 */
>> +	if (unlikely(!prev))
>> +		return;
>
> The delta will be large enough that you drop out in the check below. So you
> can spare that conditional.

Good point.

>> +
>> +	diff = now - prev;
>> +
>> +	/*
>> +	 * microsec (actually 1024th of a milisec) precision is good
>> +	 * enough for our purpose.
>> +	 */
>> +	diff >>= 10;
>
> And that shift instruction is required because of the following?
>
>>    	 * Otherwise we know the magnitude of diff is
>> +	 * well within 32 bits.
>
> AFAICT that's pointless. You are not saving anything because NSEC_PER_SEC is
> smaller than 2^32 and your 8 values are not going to overflow 64 bit in the
> sum.
>
>> +	 */
>> +	if (unlikely(diff > USEC_PER_SEC)) {
>> +		memset(timings, 0, sizeof(*timings));
>> +		timings->timestamp = now;
>
> Redundant store.

Yeah, I thought it was more efficient than:
	memset(timings->value, 0, sizeof(timings->value));
	timings->w_index = 0;
	timings->sum = 0;

>> +		return;
>> +	}
>> +
>> +	/* The oldest value corresponds to the next index. */
>> +	timings->w_index = (timings->w_index + 1) & IRQ_TIMINGS_MASK;
>> +
>> +	/*
>> +	 * Remove the oldest value from the summing. If this is the
>> +	 * first time we go through this array slot, the previous
>> +	 * value will be zero and we won't substract anything from the
>> +	 * current sum. Hence this code relies on a zero-ed structure.
>> +	 */
>> +	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 ?


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

  parent reply	other threads:[~2016-06-14 13:36 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 [this message]
2016-06-14 15:10     ` Nicolas Pitre
2016-06-14 15:38       ` Daniel Lezcano
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=57600866.4070601@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 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).