Messages in this thread | | | Date | Thu, 24 Feb 2011 13:18:05 +0100 (CET) | From | Thomas Gleixner <> | Subject | RE: 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
| |