← Previous Lecture    Next Lecture →

What You Will Learn

Prerequisites

Why Linux Kernel Sleep Functions Matter

Every driver eventually needs to wait — for hardware to settle, for a sensor to warm up, for a bus transaction to finish. The wrong choice here is expensive: spinning the CPU in a busy loop for tens of milliseconds wastes power and starves other tasks. This is precisely the gap that Linux kernel sleep functions fill. They are only valid in process context, meaning any code path where it is legal to call schedule() and hand off the CPU. Interrupt handlers, spinlock critical sections, and other atomic contexts must never call these functions.

usleep_range() — The Recommended Kernel Sleep Function

usleep_range(min, max) is the go-to Linux kernel sleep function for short delays, typically between 10 microseconds and 20 milliseconds. Instead of asking for an exact duration, you give the scheduler a window — a minimum and a maximum — which lets it coalesce your wakeup with other pending timer events. On modern kernel 6.x systems this range-based approach reduces timer interrupts and measurably improves power efficiency on mobile and embedded SoCs.

#include <linux/delay.h>

static void sensor_settle_delay(void)
{
    /* Wait between 800 and 1200 microseconds while the sensor
     * output stabilizes after a power rail change. */
    usleep_range(800, 1200);
}

The wider the gap between the minimum and maximum, the more freedom the kernel timer subsystem has to batch wakeups. A common rule of thumb: set the maximum to roughly 1.5–2x the minimum unless your hardware demands a tighter tolerance.

msleep() and msleep_interruptible() for Millisecond Delays

msleep(ms) is meant for delays of roughly 10 milliseconds and above where an exact microsecond window is unnecessary. It puts the calling task into an uninterruptible sleep state, meaning no pending signal can wake it early. This is the right behavior when a partially completed hardware sequence must not be abandoned midway.

msleep_interruptible(ms) behaves the same way but allows the sleep to be broken by a signal — useful when your driver exposes a blocking operation to user space that the user might want to cancel with Ctrl+C.

#include <linux/delay.h>

static int flash_erase_wait(void)
{
    /* Datasheet specifies a 25 ms erase pulse; a partial erase
     * would corrupt the sector, so we use the uninterruptible form. */
    msleep(25);
    return 0;
}

static int user_cancellable_wait(void)
{
    /* Allow the operator to abort a long operation with a signal. */
    if (msleep_interruptible(3000)) {
        pr_info("wait interrupted by signal\n");
        return -EINTR;
    }
    return 0;
}

ssleep() for Second-Scale Delays

ssleep(s) is a thin convenience wrapper that simply calls msleep(s * 1000). Reach for it whenever a delay is naturally expressed in whole seconds, such as waiting for a device to complete a self-test after power-up.

#include <linux/delay.h>

static void device_selftest_wait(void)
{
    /* Give the device up to 3 seconds to complete power-on self-test. */
    ssleep(3);
}

Interruptible vs Uninterruptible Sleep: Choosing Correctly

This distinction trips up many beginners writing their first Linux kernel driver. An uninterruptible sleep guarantees your delay runs to completion no matter what signals arrive for the calling process, which is essential when interrupting the operation would leave hardware in an undefined state. An interruptible sleep, by contrast, respects the UNIX philosophy of giving user space control — if the operator wants to abort, the kernel obeys.

API	Typical Duration	Interruptible?	Best Used For
usleep_range()	10μs – 20ms	N/A (non-blocking timer wait)	Short hardware settling delays
msleep()	≥10ms	No	Delays that must not be aborted
msleep_interruptible()	≥10ms	Yes	User-cancellable waits
ssleep()	≥1s	No	Second-scale power-on / self-test waits

Hands-On Example: A Kernel Module Demonstrating Safe Sleep

Below is an original demo module you can build and load yourself. It logs a timestamp before and after each sleep call so you can observe the actual elapsed time on your own machine.

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

static int __init sleep_demo_init(void)
{
    ktime_t start, end;

    pr_info("sleep_demo: module loaded\n");

    start = ktime_get();
    usleep_range(1000, 1500);
    end = ktime_get();
    pr_info("sleep_demo: usleep_range took %lld us\n",
            ktime_to_us(ktime_sub(end, start)));

    start = ktime_get();
    msleep(20);
    end = ktime_get();
    pr_info("sleep_demo: msleep took %lld us\n",
            ktime_to_us(ktime_sub(end, start)));

    return 0;
}

static void __exit sleep_demo_exit(void)
{
    pr_info("sleep_demo: module unloaded\n");
}

module_init(sleep_demo_init);
module_exit(sleep_demo_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("EmbeddedPathashala sleep function demo");

Build it with a standard out-of-tree Makefile and load it with insmod, then inspect the output with:

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

Common Mistakes When Using Kernel Sleep Functions

Best Practices for Linux Kernel Sleep Functions

Performance Considerations

On modern multi-core systems running kernel 6.x, timer coalescing driven by usleep_range()‘s window argument has a real impact on power consumption, particularly on ARM-based embedded boards and laptops using tickless idle. Every extra timer interrupt wakes the CPU out of a deeper idle state, so batching wakeups across drivers measurably extends battery life on mobile and IoT hardware.

Security Considerations

Sleep functions are rarely a direct attack surface, but incorrect use can create denial-of-service style bugs: an uninterruptible sleep held during a critical resource lock can stall unrelated processes, and an interruptible sleep used where it should not be can let unprivileged user space abort a security-relevant hardware sequence (such as a secure erase) partway through, leaving the device in an inconsistent state.

Summary & Key Takeaways

Conclusion

Mastering Linux kernel sleep functions is a small but essential skill on the road to writing production-quality device drivers. Once you understand the trade-off between usleep_range(), msleep(), msleep_interruptible(), and ssleep(), you will naturally write drivers that are both correct and power-efficient. This lecture is one part of EmbeddedPathashala’s free Linux kernel development course, and the next lecture continues building on kernel timing concepts.

Frequently Asked Questions