Latency Killer

Feel free to add more, or provide more information about the ones in this list, like the order of magnitude you've seen on your system, etc.

Most of pieces of information in this page originate from the [rtai mailing list].

Usual suspects in the killer's league

• X server on x86, which is allowed to mask interrupts (iopl+sti/cli) from user-space.
• legacy USB setup: >100ms
• SMI: >100us ?
• CPUFreq/PowerMgmt - ACPI
• APM
• Video mode emulation
• Ressource hog
  • freezing-cold I-Cache and D-Cache when entering RT world
  • freezing-cold I-TLB and D-TLB
  • CPU currently receiving exception (received but not handed out yet): ~couple of cycles
  • bus contention with busmasters (DMA, PCI, write-combining MTRR, SMP, ..), if allowed by design
  • {in,out}[bwl] on the slowish ISA I/O bus (x86 systems)
  • any other idea?

Possible solutions

• X server on x86:
  • disabling acceleration in the X configuration
  • inspect X driver source code for interrupt masking and tweak accordingly, as discussed in [this thread] of the rtai mailing list archive.
  • use Linux framebuffer instead (kernel-side device driver)
  • use DirectFB instead of X
• legacy USB setup:
  • Disable legacy USB setup in PC BIOS
  • Start Linux USB driver which resets the legacy support
  • /USB SMI
• SMI:
  • block System Management Interrupts, like explained in article about [Intel ICHx, SMI and excessive latencies] from rtai.org mailing list archive.
  • [Xenomai] and [SMI workaround]
• CPUFreq/PowerMgmt - ACPI:
  • Compile ACPI in kernel but disable power management support?
• APM:
  • Disable APM by all means (BIOS and kernel)
• Video mode:
  • Disable legacy video mode to prevent [weirdness with Geode] or systems alike, and prefer simple UART console.
• Ressource hog:
  • freezing-cold I-Cache and D-Cache when entering RT code:
    • lock code/data lines in cache if arch permits
    • make use of explicit cache prefetching (I/D)
    • store critical code/data on a separate low-latency *RAM, like an external ZBT-SRAM. Some systems are also able to turn part of complete L2 cache into a SRAM to be managed explicitly.
    • make use of a multi-CPU system as a SMP or MUP, with dedicated CPU for RT applications
  • freezing-cold I-TLB and D-TLB:
    • lock/pin TLB entries if arch permits
    • make use of bigger pages like hugetlb
  • CPU currently receiving exception (received but not handed out yet):
    • hardware dependant?
  • bus contention with busmasters (DMA, PCI, write-combining MTRR, SMP, ..), if allowed by design:
    • see DMA and jitter
    • disable hard-drive DMA: hdparm -d0 /dev/hdX
    • disable X or at the cost of X/CPU slowdown, disable MTRR in Linux kernel configuration (check with cat /proc/mtrr)
    • shorten PCI latencies with setpci

Tools to measure latency

• testsuite in RTAI distribution
• [RTAI LiveCD]
• /flushy kernel module, to exercise Cache/TLB flushing