All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
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 V7] irq: Track the interrupt timings
Date: Thu, 23 Jun 2016 10:41:57 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1606231037380.5839@nanos> (raw)
In-Reply-To: <1466183776-5296-1-git-send-email-daniel.lezcano@linaro.org>

On Fri, 17 Jun 2016, Daniel Lezcano wrote:
> The interrupt framework gives a lot of information about each interrupt.
> 
> It does not keep track of when those interrupts occur though.
> 
> This patch provides a mean to record the elapsed time between successive
> interrupt occurrences in a per-IRQ per-CPU circular buffer to help with the
> prediction of the next occurrence using a statistical model.
> 
> A new function is added to browse the different interrupts and retrieve the
> timing information stored in it.
> 
> A static key is introduced so when the irq prediction is switched off at
> runtime, we can reduce the overhead near to zero. The irq timings is
> supposed to be potentially used by different sub-systems and for this reason
> the static key is a ref counter, so when the last use releases the irq
> timings that will result on the effective deactivation of the irq measurement.

Before merging this I really have to ask a few more questions. I'm a bit
worried about the usage site of this. It's going to iterate over all
interrupts in the system to do a next interrupt prediction. On larger machines
that's going to be quite some work and you touch a gazillion of cache lines
and many of them just to figure out that nothing happened.

Is it really required to do this per interrupt rather than providing per cpu
statistics of interrupts which arrived in the last X seconds or whatever
timeframe is relevant for this.

Thanks,

	tglx

  reply	other threads:[~2016-06-23  8:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 16:33 [PATCH V5] irq: Track the interrupt timings Daniel Lezcano
2016-06-14 17:46 ` Nicolas Pitre
2016-06-14 18:11   ` Thomas Gleixner
2016-06-14 19:52     ` Daniel Lezcano
2016-06-14 20:10     ` [PATCH V6] " Daniel Lezcano
2016-06-14 20:38       ` Nicolas Pitre
2016-06-17 13:46       ` Thomas Gleixner
2016-06-17 17:16         ` [PATCH V7] " Daniel Lezcano
2016-06-23  8:41           ` Thomas Gleixner [this message]
2016-06-23  9:39             ` Daniel Lezcano
2016-06-23 10:12               ` Thomas Gleixner
2016-06-23 13:12                 ` Daniel Lezcano

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=alpine.DEB.2.11.1606231037380.5839@nanos \
    --to=tglx@linutronix.de \
    --cc=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=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.