lkml.org 
[lkml]   [2011]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: Interrupt Latencies
Frank,

On Thu, 24 Feb 2011, Schaefer Dr, Frank-Rene () wrote:

> In response to Thomas Gleixner:
>
> > Interrupt latency depends on various factors:
> >
> > - Interrupt disabled code regions
> Could you tell us how this could be detected or measured?
> Is there a central place, where we could toggle a pin to
> see when interrupts are enabled/disabled?

ftrace allows you to analyse that.

> > - Concurrent interrupts and the ordering of handling
> We are only considering the best times that we measure.

Ok.

> > - Deep idle states
> You mean 'suspend' or some type of CPU sleep. Could you elaborate?
> We do not suspend. This should also only be the case for the
> first chunk that is transmitted. But the latencies remain
> over longer time spans.

NOHZ idle can push the cpu into deeper power states (C2/C3). But there
are also BIOSes which do agressive power management behind the kernels
back.

Turn off CONFIG_NOHZ and add "processor.max_cstate=1" to the kernel
command line. You might also try "idle=poll" for a test.

> > - Bus contention
> Nothing else is running.

That does not guarantee anything. Think DMA.

> > How is that interrupt connected to the CPU/chipset?
> The port is part of the chipset connected internally
> via PCI.
>
> > Which driver(s) is/are involved ?
> http://lxr.free-electrons.com/source/drivers/gpio/pl061.c
>
> > How is the pin OUT accessed from the driver?
> gpio_set_value(Pin, Value);
>
> we measured the delay and could find that it was in the range
> of some nano seconds.

Is the SPI controller part of the chipset or comes the interrupt via
one of the GPIOs as well?

Thanks,

tglx


\
 
 \ /
  Last update: 2011-02-24 13:21    [W:0.054 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site