public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org,
	peterz@infradead.org, rafael@kernel.org,
	vincent.guittot@linaro.org
Subject: Re: [PATCH V8 3/3] irq: Compute the periodic interval for interrupts
Date: Fri, 24 Mar 2017 15:14:37 +0100	[thread overview]
Message-ID: <20170324141437.GD24630@mai> (raw)
In-Reply-To: <alpine.LFD.2.20.1703231514580.2304@knanqh.ubzr>

On Thu, Mar 23, 2017 at 03:40:39PM -0400, Nicolas Pitre wrote:
> On Thu, 23 Mar 2017, Daniel Lezcano wrote:
> 
> > +	/*
> > +	 * Online variance divided by the number of elements if there
> > +	 * is more than one sample.
> > +	 */
> > +	if (likely(irqs->count > 1))
> > +		variance = div_u64(irqs->variance, irqs->count - 1);
> 
> Isn't it mostly likely that irqs->count will be equal to 
> IRQ_TIMINGS_SIZE in most cases?  And if so, given that IRQ_TIMINGS_SIZE 
> == 32, we _could_ possibly approximate the division by 31 with a 
> division by 32 without affecting too much the final outcome.  Then the 
> very expensive div_u64() could be replaced by:
> 
> 	variance = irqs->variance >> 5;
> 
> Or at least keep a constant divisor that div_u64() is able to optimize 
> with a reciprocal multiplication.
> 
> This is even more important by the fact that this function is called 
> in a loop, up to IRQ_TIMINGS_SIZE times.

There is no general rule about that. Depending on the load of the system, the
cpu number, etc ... they can be a few or a the max or in between.

> > +	 * The rule of thumb in statistics for the normal distribution
> > +	 * is having at least 30 samples in order to have the model to
> > +	 * apply. Values outside the interval are considered as an
> > +	 * anomaly.
> > +	 */
> > +	if ((irqs->count >= 30) && ((diff * diff) > (9 * variance))) {
> > +		/*
> > +		 * After three consecutive anomalies, we reset the
> > +		 * stats as it is no longer stable enough.
> > +		 */
> > +		if (irqs->anomalies++ >= 3) {
> > +			memset(irqs, 0, sizeof(*irqs));
> > +			irqs->lts = ts;
> > +			return;
> > +		}
> > +	} else {
> > +		/*
> > +		 * The anomalies must be consecutives, so at this
> > +		 * point, we reset the anomalies counter.
> > +		 */
> > +		irqs->anomalies = 0;
> > +	}
> > +
> > +	/*
> > +	 * The interrupt is considered stable enough to try to predict
> > +	 * the next event on it.
> > +	 */
> > +	irqs->valid = 1;
> > +
> > +	/*
> > +	 * Online average algorithm:
> > +	 *
> > +	 *  new_average = average + ((value - average) / count)
> > +	 *
> > +	 * The variance computation depends on the new average
> > +	 * to be computed here first.
> > +	 *
> > +	 */
> > +	irqs->avg = irqs->avg + div_s64(diff, irqs->count);
> 
> Why not computing the average outside this function in a loop of its 
> own?  This way you'd have only one division to perform instead of 32.
> The above is also skewed as it gives way more weight to the initial 
> samples when irqs->count is still low.

Actually, stabilizing the math in this function has been the major effort with
this patch.

Changing the above won't save us anything because we have to compute the
variance each time in order to put apart the new value or not.

I understand a div64 can be scary but, I would like to put in place the
framework. Then we can think about optimizing the 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

  reply	other threads:[~2017-03-24 14:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 17:42 [PATCH V8 1/3] irq: Add flags to request_percpu_irq function Daniel Lezcano
2017-03-23 17:42 ` [PATCH V8 2/3] irq: Track the interrupt timings Daniel Lezcano
2017-03-23 18:35   ` Peter Zijlstra
2017-03-23 19:02     ` Daniel Lezcano
2017-03-23 19:06       ` Nicolas Pitre
2017-03-23 19:14   ` Nicolas Pitre
2017-03-23 19:38     ` Thomas Gleixner
2017-03-23 19:50       ` Nicolas Pitre
2017-03-23 21:17         ` Thomas Gleixner
2017-03-23 17:42 ` [PATCH V8 3/3] irq: Compute the periodic interval for interrupts Daniel Lezcano
2017-03-23 19:40   ` Nicolas Pitre
2017-03-24 14:14     ` Daniel Lezcano [this message]
2017-03-23 18:34 ` [PATCH V8 1/3] irq: Add flags to request_percpu_irq function Vineet Gupta
2017-03-23 18:54 ` Mark Rutland
2017-03-23 19:19   ` Daniel Lezcano
2017-03-27  8:44 ` Andrew Jones

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=20170324141437.GD24630@mai \
    --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=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