1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Linux Dynticks Being Extended For Performance Wins

Linux Kernel

Published on 18 December 2012 03:34 AM EST
Written by Michael Larabel in Linux Kernel
5 Comments

Dynticks, the Dynamic Tick Timer for allowing the Linux kernel to skip ticks while idling and resume to running at full HZ when encountering load, is in the process of being extended. Developers are working on making Dynticks work even under select workloads in order to enhance the performance of CPU-intensive tasks.

Dynticks up to this point has been a power savings win for Linux systems that are frequently idling since the tick timer goes off much less frequently. However, Dynticks can also be a performance win if the kernel can tick less while experiencing high CPU load. Developers have been working towards this feat and some of the bits are likely to be merged into the Linux 3.8 kernel.

There's an outstanding pull request for full Dynticks support for printk, the Linux kernel print function, in Linux 3.8. The pull request can be found below and describes what's being done for making Dynticks more relevant to CPU-intense workloads.

Frederic Weisbecker wrote:
We are currently working on extending the dynticks mode to broader contexts than just idle. Under some conditions on a busy CPU, the tick can be avoided (no need of preemption for one task running, no need of RCU state machine maintainance in userspace, etc...).

The most popular application of this is the implementation of CPU isolation. On HPC workloads, where people run one task per-CPU in order to maximize the CPU performances, the kernel sets itself too much on the way with these often unnecessary interrupts.

The result is a performance loss due to stolen CPU time and cache trashing of the userspace workset.

Now CPU isolation is the most famous user. I expect more. For example we should be able to avoid the tick when we run in guest mode. And more generally this may be a win for most CPU-bound workloads.

So in order to implement this full dynticks mode, we need to find alternatives to handle the many maintainance operations performed periodically and turn them to more one-shot event driven solutions.

printk() is part of the problem. It must be safely callable from most places and for that purpose it performs an asynchronous wake up of the readers by probing on the tick for pending messages and readers through printk_tick().

Of course if we use printk while the tick is stopped, the pending readers may not be woken up for a while. So a solution to make printk() working even if the CPU is in dynticks mode
is to use the irq_work subsystem. This subsystem is typically able to fire self-IPIs. So when printk() is called, it now enqueues an irq_work that does the asynchronous wakeup:

* If the tick is stopped, it raises a self-IPI
* If the tick is running periodically then don't fire a self-IPI but wait for the next tick to handle that instead (irq work probes on the timer tick). This avoids self-IPIs storm in case of frequent printk() in short periods of time.

I know this is a sensitive area. We want printk() to stay minimal and not rely too much on other subsystems that add complications and that may use printk themselves. That's why we chose irq_work because:

- It's pretty small and self-contained
- It's lockless
- It handles most recursivity cases (if it uses printk() itself from the IPI path, this won't fire another IPI)

But because it's sensitive, I'm proposing it as an RFC pull request.
A win for most CPU-bound workloads? Yes please. Linus has yet to respond whether he will honor this merge request for the Linux 3.8 release.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  2. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  3. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  4. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
Latest Linux Articles
  1. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  2. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  3. Testing For The Latest Linux Kernel Power Regression
  4. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
Latest Linux News
  1. Nouveau X.Org Driver Released With DRI3+Present, Maxwell, GLAMOR
  2. Microsoft & AMD Release C++ AMP Compiler With Linux Support
  3. AMD, Wine & Valve Dominated August For Linux Users
  4. Linux 3.17-rc3 Kernel Released Back On Schedule
  5. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  6. Mesa 10.3 RC2 Arrives Via Its New Release Manager
  7. Ubuntu 14.10's Lack Of X.Org Server 1.16 Gets Blamed On AMD
  8. MSI Motherboard BIOS Updating Remains A Pain For Linux Users
  9. See How Your Linux System Performs Against The Latest Intel/AMD CPUs
  10. AMD Steppe Eagle Flys To Coreboot
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. SSD seems slow
  3. AMD Releases UVD Video Decode Support For R600 GPUs
  4. Is laptop with Intel CPU and AMD dGPU worth buying considering especially AMD Enduro?
  5. Radeon HD5670 and Ubuntu 14.04
  6. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  7. Updated graphics drivers for Ubuntu 12.04 Precise LTS
  8. Catalyst 14.201.1008