← Previous Lecture    Next Lecture →

What You Will Learn

Prerequisites

Why You Need an Accurate Linux Kernel Timestamp

Tools like dmesg and Ftrace already print timing information, but as soon as you need to measure something specific — how long a register write takes to complete, how long your workqueue handler runs, how much latency an interrupt handler adds — you need to take your own Linux kernel timestamp directly in code. The kernel exposes a family of ktime_get_*() functions for exactly this purpose, replacing older and less precise approaches.

ktime_get_real_ns(): Reading Wall-Clock Time in Nanoseconds

u64 ktime_get_real_ns(void) returns the current wall-clock time as a 64-bit nanosecond value. Internally it queries the real-time clock source and converts the result to nanoseconds, giving you a human-meaningful timestamp rather than an opaque counter. It is the natural choice whenever you want to log “what time did this happen” rather than “how long did this take.”

#include <linux/ktime.h>

static void log_event_timestamp(void)
{
    u64 now_ns = ktime_get_real_ns();

    pr_info("event occurred at %llu ns since epoch\n", now_ns);
}

ktime_get_real_ns() vs ktime_get_ns(): Choosing the Right Clock

A common point of confusion in any Linux kernel timestamp tutorial is picking between the “real” clock and the monotonic clock. The table below summarizes the practical difference.

Function	Clock Source	Affected by Time Changes?	Best Used For
ktime_get_real_ns()	Wall-clock (CLOCK_REALTIME)	Yes — NTP/manual adjustments shift it	Logging real-world event times
ktime_get_ns()	Monotonic	No — always moves forward steadily	Measuring elapsed durations / benchmarking
ktime_get_real_fast_ns()	Wall-clock, NMI-safe fast path	Yes	Timestamping inside NMI or very hot paths

Rule of thumb: if you are measuring “how long did X take,” use the monotonic ktime_get_ns() so an NTP adjustment mid-measurement cannot corrupt your result. Reach for ktime_get_real_ns() only when you need an actual calendar timestamp to log or compare against external events.

Hands-On Example: Timing a Kernel Routine

The following original demo module measures how long a small computation takes, logging both a wall-clock start timestamp and the elapsed duration — demonstrating both functions together in one place.

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/ktime.h>

static void do_sample_work(void)
{
    volatile int i;
    int sum = 0;

    for (i = 0; i < 100000; i++)
        sum += i;
}

static int __init timestamp_demo_init(void)
{
    u64 wall_clock_ns = ktime_get_real_ns();
    u64 start = ktime_get_ns();
    u64 end;

    pr_info("timestamp_demo: starting at %llu ns since epoch\n", wall_clock_ns);

    do_sample_work();

    end = ktime_get_ns();
    pr_info("timestamp_demo: do_sample_work took %llu ns\n", end - start);

    return 0;
}

static void __exit timestamp_demo_exit(void)
{
    pr_info("timestamp_demo: module unloaded\n");
}

module_init(timestamp_demo_init);
module_exit(timestamp_demo_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("EmbeddedPathashala kernel timestamp demo");

Build and load it, then check the kernel log:

sudo insmod timestamp_demo.ko
dmesg | tail -n 5
sudo rmmod timestamp_demo

Real-World Use Cases

Common Mistakes and Troubleshooting

Best Practices

Performance Considerations

Calling ktime_get_*() is cheap on modern kernel 6.x systems with a good clocksource such as TSC on x86 or the ARM generic timer, typically costing tens of nanoseconds. Even so, sprinkling timestamp calls inside a hot loop that runs millions of times per second will show up in profiles. For that level of measurement, dedicated tracing infrastructure like Ftrace is a better fit than manual ktime calls.

Security Considerations

Because ktime_get_real_ns() tracks wall-clock time, any code that uses it for security-relevant decisions (such as token expiry checks) can be affected by an administrator or NTP adjusting the system clock. For security-sensitive timing logic, prefer the monotonic clock so that clock adjustments cannot be used to bypass a check.

Summary & Key Takeaways

Conclusion

Accurate timing is a foundational skill for any kernel or device driver developer, and the ktime API family makes it straightforward once you know which function answers which question. This lecture wraps up the timing-related portion of EmbeddedPathashala’s free Linux kernel development course; continue to the next lecture to keep building your free Linux device drivers course skill set.

Frequently Asked Questions