Clocks and Timers

The period is set to 100 ms, but the actual time per round is about 130 ms; after cancellation returns, the callback appears again. The former is the time base, and the latter is the lifetime protocol.

The clock tells the kernel where time has reached, the timer records what should happen in the future, and the scheduler decides when the woken-up tasks actually run. The latency of these three stages must be separated; you cannot guarantee that an application will wake up with nanosecond error just because clock_getres returns nanosecond resolution.

1. Clocksource and clockevent

clocksource provides a readable counter. The kernel updates time based on the counter difference, mask, and conversion parameters; the counter frequency does not necessarily equal the current CPU execution frequency.

clockevent is responsible for generating notifications in the future. set_next_event() receives the delta in the device's corresponding count units, not all devices uniformly receive nanoseconds; interfaces like set_next_ktime() can use direct time values. The core is responsible for conversion and constraints such as device minimum/maximum ranges.

The same hardware device may support both responsibilities, or they may be handled by different hardware. For example, a readable TSC does not directly equal a traditional APIC timer; mechanisms like TSC deadline provide event capabilities based on corresponding counts. When a CPU is deeply idle, local event devices may need a broadcast mechanism for assistance. See timekeeping hardware abstraction.

2. Jiffies, HZ, and Wraparound

jiffies is the kernel's coarse-grained time counter, and HZ specifies the related tick scale. A tickless system still maintains logical time and does not require each CPU to receive exactly HZ timer interrupts per second.

getconf CLK_TCK returns the timekeeping unit for the user-space interface; you cannot use it to directly read CONFIG_HZ. When HZ=250, one jiffy is 4 ms, which does not mean all hrtimers can only be programmed in 4 ms increments.

With a 32-bit unsigned long, 2^32 counts wrap around in approximately 497 days at HZ=100, and in approximately 49.7 days at HZ=1000. Expiry comparisons should use macros like time_after/time_before, and adhere to the corresponding distance ranges; you cannot use jiffies > expires as a portable timeout check. You also cannot infinitely rely on half-range difference comparisons for very distant future intervals.

Use APIs like msecs_to_jiffies() for millisecond conversions to avoid truncating short delays to zero via manual integer division, or ignoring overflow and upper limits.

3. Why Timer Wheel and hrtimer Coexist

Timers are not "appointments that must execute precisely at expiry." IRQ disabling, CPU busy, thread priority, and VM suspension can all cause processing delays; high precision mainly improves the ability to schedule expiries, it does not directly provide hard real-time upper bounds.

Standard timer callbacks usually execute under TIMER_SOFTIRQ semantics and cannot sleep arbitrarily. The hard/soft mode of hrtimers and the PREEMPT_RT configuration affect the actual callback context; you cannot uniformly say "hrtimer is always in HRTIMER_SOFTIRQ" or "always in hardirq."

If blocking work needs to be executed, the callback can schedule an appropriate standard workqueue or wake up a task. schedule_hrtimeout() is an interface for the caller to wait; it does not convert a callback already in atomic context into a sleepable function. See hrtimer design.

4. Lifetime Issues in Initialization, Cancellation, and Rearming

New code should use timer_setup() to initialize timer_list; the current kernel provides hrtimer_setup() to initialize hrtimers, while older targets may still require legacy initialization interfaces, so you must check the target headers.

Therefore, the exit protocol must coordinate queued state, current callbacks, and future accessors simultaneously.

Modern timer_list uses timer_shutdown_sync() for exit scenarios requiring synchronous stop and prevention of rearming, especially when timers and work reschedule each other. The names del_timer/del_timer_sync in old code and the current timer_delete series should be checked against the target version; do not comment standard del_timer as "synchronous delete."

Even with shutdown, you must prevent future paths from accessing the released timer object; "rearming a live but shut-down timer is ignored" does not mean "you can call APIs on a dangling timer pointer." hrtimer_cancel also needs to coordinate with publishers/rearmer.

Do not hold locks required by the callback during cancellation

If a thread holds lock L and calls synchronous cancellation, and the callback has already started and is waiting for L, both sides will wait for each other. The exit should first stop new submission paths, synchronously wait without holding mutually dependent locks, and then release the timer, work, and their shared context.

5. Which Base to Use for Periodic Tasks

Assume a period of 100 ms and a processing time of 30 ms per round, comparing the start times of previous rounds:

Here, other scheduling delays are ignored. An absolute base avoids repeatedly adding working time into the period, but after an actual timeout, you still need to decide whether to catch up, skip, or merge.

Interfaces like hrtimer_forward help advance the expiry point and report crossed periods; they only restart according to the corresponding rules when HRTIMER_RESTART is returned; they do not automatically execute a full business callback for each missed period.

User-space can also use clock_nanosleep(..., TIMER_ABSTIME, ...) or timerfd absolute time mode to reduce relative sleep drift. Choosing MONOTONIC, BOOTTIME, or REALTIME determines how time synchronization and suspension affect deadlines.

hrtimer_forward advances deadlines and reports overruns; HRTIMER_RESTART requests restarting under its rules. It does not execute one business callback for every missed period. Userspace can use TIMER_ABSTIME with clock_nanosleep or timerfd; the clock choice determines suspend and wall-clock adjustment semantics.

$$t_n^{\mathrm{relative}}=n(P+C+J)+J,t_n^{\mathrm{absolute}}=nP+J$$

n starts at zero; P is the period, C callback work, and J a fixed dispatch delay. This parameter range does not overload the absolute schedule; real jitter need not be constant.

6. NO_HTZ Reduces Ticks, But Does Not Eliminate All Interrupts

NO_HZ_IDLE stops periodic scheduling ticks under suitable idle conditions, waking up based on the next event that needs processing. NO_HZ_FULL further reduces ticks during running tasks on selected CPUs and under load conditions that meet requirements, but there are still maintenance tasks, RCU, timers, and device interrupts.

"Only one runnable task" is one of the relevant conditions; it does not guarantee that there will never be ticks under any configuration. Housekeeping CPU and task/IRQ affinity must also be coordinated; nohz_full is not a complete CPU isolation configuration.

cpuidle's state*/disable indicates whether certain idle states are allowed; you cannot directly judge the current tick mode. You should combine kernel configuration, boot parameters, and actual tracing. See NO_HZ documentation.

7. POSIX timer, itimer, and timerfd

Wall-clock POSIX timers like CLOCK_MONOTONIC/REALTIME and CPU-time timers have different timekeeping sources; you cannot claim that all timer_create calls directly correspond to the same type of hrtimer. Notification mechanisms such as SIGEV_SIGNAL, SIGEV_NONE, and library-involved SIGEV_THREAD also differ.

setitimer's REAL times based on elapsed time, VIRTUAL based on user CPU time, and PROF based on user and kernel CPU time; CPU-time timers should not be treated as standard sleep timeouts. Signal merging, overrun, and processing delays will also affect application observation.

timerfd notifies via fd readability; read gets a 64-bit cumulative expiry count, not a timestamp, and does not guarantee that each poll readability corresponds to exactly one expiry. The following program only creates a MONOTONIC timer for this process, waits for about 75 ms, and then reads the cumulative count for a 20 ms period.

#define _POSIX_C_SOURCE 200809L
#include <errno.h>
#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <sys/timerfd.h>
#include <time.h>
#include <unistd.h>

int main(void)
{
    int fd = timerfd_create(CLOCK_MONOTONIC, TFD_CLOEXEC);
    if (fd < 0) { perror("timerfd_create"); return 1; }
    struct itimerspec spec = {
        .it_interval = { .tv_nsec = 20000000 },
        .it_value = { .tv_nsec = 20000000 }
    };
    if (timerfd_settime(fd, 0, &spec, NULL) < 0) {
        perror("timerfd_settime"); close(fd); return 1;
    }
    struct timespec delay = { .tv_nsec = 75000000 };
    while (nanosleep(&delay, &delay) < 0) {
        if (errno != EINTR) { perror("nanosleep"); close(fd); return 1; }
    }
    uint64_t count;
    ssize_t n;
    do { n = read(fd, &count, sizeof(count)); } while (n < 0 && errno == EINTR);
    if (n != sizeof(count)) { fprintf(stderr, "timerfd read failed\n"); close(fd); return 1; }
    printf("expirations=%" PRIu64 "\n", count);
    close(fd);
    return count >= 3 ? 0 : 1;
}

cc -std=c11 -O2 -Wall -Wextra -Werror timer-count.c -o timer-count
./timer-count

The typical result is 3, but it may be higher due to scheduling delays; you cannot assert that it is always exactly 3. Closing the fd reclaims the timer; this example does not modify the system clock. See timerfd for details.