Low-Latency Kernel? WTF?!?!

Lots of people hear “Low-Latency”, say “Woohoo!” and run to recompile their Linux kernel…

…only to discover, with great dismay, that their PC’s overall performance just dropped to the floor. Bum!

Here’s why, folks!

Graph showing low-latency changes

In the first timeline we have some inputs.

  • They have a certain priority
  • One of them (painted in orange) requires a real-time answer (the answer is not valid if it comes too late)
  • There is no way to predict inputs (otherwise the inputs would have been ordered as so: RT – 2 – 1 – 0)
  • Every input triggers a task that requires 4 CPU cycles to be executed
  • The CPU context switch is done in 1 cycle.

 

In the second timeline we have a FIFO (First In First Out) scheduling that guarantees high throughput.

  • Context switches (painted in blue) occur with low frequency
  • Every job is done at full speed
  • All jobs are done in a small amount of time
  • But: the real-time input received a high latency (the answer came too late)
  • Conclusion: this scheduling is not really suitable for a desktop environment, absolutely not when there are hard real-time requirements
    • Audio/video applications require lower latencies.
    • The PC seems less responsive to user inputs even if it’s doing all his tasks in the smallest time.

In the third timeline we have a low-latency scheduling.

  • Context switches are more frequent
  • The real-time input has received a low latency and its task is executed before the completion of red and yellow tasks.
  • But: the overall performance is worse (it takes more time to finish all the jobs)
  • Conclusion: this scheduling is not suitable for a server environment
    • Some tasks might never be finished if their priority is low
    • The red task is done in a very long time (usually on a server tasks have similar priorities)

So what am I trying to say?

  • If you’re doing professional audio/video editing, or are building up a “media center”, then a low-latency kernel might be good for you.
    • Have a look at Ingo Molnar’s “Realtime-Preemption” patches
    • Be ready to have more cups of coffee while your low-latency system builds another kernel
    • You won’t lose a single DVD frame and your wobbly windows will be really wobbly :o)
  • If you’re building a HARD real-time system, then you need something more than a different scheduler.
    • You may be interested in the RTAI patch
    • Get a DVD player and forget about wobbly windows
  • If you simply want a more responsive desktop system without degrading overall performance, then Con Kolivas’ patches do the job.
    • Beware! The kernel must be 2.6.22 or lower! Con Kolivas is not doing new patches.
    • It makes an intensive use of swap memory: your HD will work a lot
    • There is a server version, too
  • If you’re building a server system, then the “vanilla” kernel compiled with a “Timer Frequency” value set to 100Hz is OK.
    • In the worst case you’ll have a context switch only every 0.01 sec. (for maximum throughput).
    • Desktop PCs usually do a context switch every 0.001 sec. (medium throughput, better responsiveness).
About these ads

6 pensieri su “Low-Latency Kernel? WTF?!?!

  1. The world has changed, and so has the Linux kernel :) nowadays I’d suggest to have a look at cgroups.

    Basically you can define that a group of processes will be granted a certain portion of memory, CPU time, CPU cores.

    Or limited to, in the case of MATLAB… heck, it’s eating away 750+ MB of memory at startup!

  2. Pingback: I kernels in Ubuntu | maurizio siagri
  3. Hmmm

    I have an old dell precision m2300 was lighting fast with older kernels and desktops. But it can no longer run ubuntu even xbuntu decently. Tried many other light desros. Its just ways too slow until along comes low latency kernel. Im running now ubuntu studio. And it runs like it was on its old days. Everything is very fast

    • Hello Nash,

      I agree it’s more responsive, that’s the purpose of low latency kernels: responding fast to events such as user inputs.

      But it’s likely that a long job (like a debian kernel recompilation) will take less time with a standard kernel than with a low-latency one.

      Not really on-topic, but you should consider using the “performance” CPU frequency governor instead of the “ondemand” one when your laptop is plugged in. I’ve seen that the ondemand one performs badly on certain cpus (p4m above all) where the accent was on the max cpu frequency rather than on the number of cores.

      Cheers

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...