lkml.org 
[lkml]   [2016]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH V7] irq: Track the interrupt timings
From
Date
On 06/23/2016 10:41 AM, Thomas Gleixner wrote:
> 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.

Perhaps I am misunderstanding but if the statistics are done per cpu
without tracking per irq timings, it is not possible to extract a
repeating pattern for each irq and have an accurate prediction.

Today, the code stores per cpu and per irq timings and the usage is to
compute the next irq event by taking the earliest next irq event on the
current cpu.

@@ -51,6 +52,9 @@ struct irq_desc {
struct irq_data irq_data;
unsigned int __percpu *kstat_irqs;
irq_flow_handler_t handle_irq;
+#ifdef CONFIG_IRQ_TIMINGS
+ struct irq_timings __percpu *timings;
+#endif
#ifdef CONFIG_IRQ_PREFLOW_FASTEOI
irq_preflow_handler_t preflow_handler;
#endif
If we step back and look at the potential users of this framework, we have:

- mobile: by nature the interrupt line number is small and the devices
are "slow"

- desktop and laptop : a few interrupts are really interesting us,
ethernet and sdd (the other ones are rare, or ignored like timers or IPI)

- server : the interrupt line number is bigger, but not so much.

- other big system: I don't know

Usually, server and super sized system want full performance and low
latency. For this reason the kernel is configured with periodic tick and
that makes the next prediction algorithm superfluous, especially when
the latency is set to 0. So I don't think the irq timings + next irq
event code path will be ever used in this case.

As you mentioned it, there are some parts we can make evolve and
optimize like preventing to lookup an empty irq events cpu.





--
<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
\
 
 \ /
  Last update: 2016-06-23 12:21    [W:0.072 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site