Lowering Linux Kernel Timer Frequency

Lowering linux kernel timer frequency

Don't worry! Your confusion is nothing but expected. Linux timer interrupts are very confusing and have had a long and quite exciting history.

CLK_TCK

Linux has no sysconf system call and glibc is just returning the constant value 100. Sorry.

HZ <-- what you probably want

When configuring your kernel you can choose a timer frequency of either 100Hz, 250Hz, 300Hz or 1000Hz. All of these are supported, and although 1000Hz is the default it's not always the best.

People will generally choose a high value when they value latency (a desktop or a webserver) and a low value when they value throughput (HPC).

CONFIG_HIGH_RES_TIMERS

This has nothing to do with timer interrupts, it's just a mechanism that allows you to have higher resolution timers. This basically means that timeouts on calls like select can be more accurate than 1/HZ seconds.

divider

This command line option is a patch provided by Red Hat. You can probably use this (if you're using Red Hat or CentOS), but I'd be careful. It's caused lots of bugs and you should probably just recompile with a different Hz value.

CONFIG_NO_HZ

This really doesn't do much, it's for power saving and it means that the ticks will stop (or at least become less frequent) when nothing is executing. This is probably already enabled on your kernel. It doesn't make any difference when at least one task is runnable.

Frederic Weisbecker actually has a patch pending which generalizes this to cases where only a single task is running, but it's a little way off yet.

How to change kernel timer frequency?

Changes you make to /boot/config do not affect the running kernel. Please read more about the kernel config file here.

The config file you see in /boot/config (actually, it's more like config-[kernel_version]) is the config file that was USED to build the kernel. This means that every change you make to this config file does not affect anything.

To really make these changes you need to construct a new config file, with the modifications you require and compile and install a new kernel based on that config file. You can use the config file from /boot and just make the clock adjustments to fit.

Change linux kernel timer

Don't edit .config directly, unless you're a Kbuild expert (and if you're asking this, you're not a Kbuild expert). Instead run make menuconfig or make xconfig to load the menu-based configuration system. Alternately, make config will do a line-based configuration process (where it asks you several hundred questions about what to configure - not recommended). The relevant option is under "Processor type and features" as "Timer frequency".

That said, this may not be necessary. Modern Linux can use high-resolution event timers (CONFIG_HIGH_RES_TIMERS) to acheive low-latency timers even without increasing the timer frequency. With a tickless system (CONFIG_NO_HZ) , the timer frequency has little effect at all.

On the other hand, I'm not sure what timer support Geode CPUs have. You may want to run cyclictest with various kernel configurations to see what you need to get low latency performance. The test you ran tests maximum dispatch frequency, not dispatch latency, so comparing with cyclictest results would be interesting. If you need really low latency, the CONFIG_PREEMPT_RT patchset may also be of interest.

Change kernel time frequency

It's easy enough to download sources. You can actually, on ubuntu, run:

apt-get source linux-image-amd64-4.4.0-83-generic
apt-get build-dep linux-image-amd64-4.4.0-83-generic

The first command will download the source for that kernel (to the current directory); the second will install all packages needed to build it. When that's done, enter the linux-image folder, and

zcat /proc/config.gz > .config

This will get the currently-running kernel config into this build area. Finally, make menuconfig

will open a text-based menu system. Press / to search, and find HZ. Browse to the setting, press <Enter> to open it, and select 1000. Exit out, saving the config, then make bzImage modules -j9 to build the kernel (replacing 9 with one more than your CPU core/thread count for speed).

make install will put the kernel and modules into /boot and /lib/modules/kernel_name_and_version respectively.

Understanding the `scheduler_tick()` function of Linux Kernel

Answering your main questions and comments at the same time:

1. It's not possible for scheduler code to be called while already scheduling, as it runs with interrupts disabled.
2. Yes, each core has its own runqueue and does its own scheduling.
3. It's the opposite: high HZ -> scheduler will run more frequently (since HZ represents the number of scheduling ticks per second); low HZ -> scheduler will run less frequently.

Scheduling on every single core simultaneously is not needed, each CPU has its own timer and does its own timer interrupts regardless of sync with other CPUs. Scheduler ticks don't happen at the same time on all CPUs (furthermore CPUs could be idle and not ticking at all in a "tickless" kernel, configured with CONFIG_NOHZ). Tickless kernels make things a bit tricker, for more info check out Documentation/timers/NO_HZ.txt and "How are jiffies incremented in a tickless kernel?".

As per what trigger_load_balance() does and how, see Documentation/scheduler/sched-domains.txt, which explains it more or less in detail. In particular, trigger_load_balance() doesn't do the actual load balancing, it just checks if it's needed and if so raises a soft IRQ (SCHED_SOFTIRQ), which is then handled by run_rebalance_domains(), which calls rebalance_domains(), which does the actual work. The latter function indeed uses RCU/locking, as you can see by the calls to functions such as spin_trylock() and rcu_read_lock().

---

Related Topics