Wie im Linux-Kernel schlafen?

Lesezeit: 4 Minuten

Benutzeravatar von John Roberts
John Roberts

Kann ich die msleep()-Funktion verwenden, um für eine bestimmte Zeit im Kernel-Space zu schlafen? Wenn ja, welche Header-Dateien muss ich einbinden? #include <linux/time.h> scheint nicht der richtige zu sein. Gibt es vielleicht eine bessere Funktion für diesen Zweck?

musste ich einbeziehen <linux/delay.h> um msleep im Kernelspace zu verwenden.

Ciro Santilli Benutzeravatar von OurBigBook.com
Ciro Santilli OurBigBook.com


Die Linux-Kernel-Dokumentation unter Documentation/timers/timers-howto.txt hat einen guten Überblick über die wichtigsten Methoden:

Inserting Delays

The first, and most important, question you need to ask is "Is my
code in an atomic context?"  This should be followed closely by "Does
it really need to delay in atomic context?" If so...

    You must use the *delay family of functions. These
    functions use the jiffie estimation of clock speed
    and will busy wait for enough loop cycles to achieve
    the desired delay:

    ndelay(unsigned long nsecs)
    udelay(unsigned long usecs)
    mdelay(unsigned long msecs)

    udelay is the generally preferred API; ndelay-level
    precision may not actually exist on many non-PC devices.

    mdelay is macro wrapper around udelay, to account for
    possible overflow when passing large arguments to udelay.
    In general, use of mdelay is discouraged and code should
    be refactored to allow for the use of msleep.

    You should use the *sleep[_range] family of functions.
    There are a few more options here, while any of them may
    work correctly, using the "right" sleep function will
    help the scheduler, power management, and just make your
    driver better :)

    -- Backed by busy-wait loop:
        udelay(unsigned long usecs)
    -- Backed by hrtimers:
        usleep_range(unsigned long min, unsigned long max)
    -- Backed by jiffies / legacy_timers
        msleep(unsigned long msecs)
        msleep_interruptible(unsigned long msecs)

    Unlike the *delay family, the underlying mechanism
    driving each of these calls varies, thus there are
    quirks you should be aware of.

    SLEEPING FOR "A FEW" USECS ( < ~10us? ):
        * Use udelay

        - Why not usleep?
            On slower systems, (embedded, OR perhaps a speed-
            stepped PC!) the overhead of setting up the hrtimers
            for usleep *may* not be worth it. Such an evaluation
            will obviously depend on your specific situation, but
            it is something to be aware of.

        * Use usleep_range

        - Why not msleep for (1ms - 20ms)?
            Explained originally here:
            msleep(1~20) may not do what the caller intends, and
            will often sleep longer (~20 ms actual sleep for any
            value given in the 1~20ms range). In many cases this
            is not the desired behavior.

        - Why is there no "usleep" / What is a good range?
            Since usleep_range is built on top of hrtimers, the
            wakeup will be very precise (ish), thus a simple
            usleep function would likely introduce a large number
            of undesired interrupts.

            With the introduction of a range, the scheduler is
            free to coalesce your wakeup with any other wakeup
            that may have happened for other reasons, or at the
            worst case, fire an interrupt for your upper bound.

            The larger a range you supply, the greater a chance
            that you will not trigger an interrupt; this should
            be balanced with what is an acceptable upper bound on
            delay / performance for your specific code path. Exact
            tolerances here are very situation specific, thus it
            is left to the caller to determine a reasonable range.

        * Use msleep or possibly msleep_interruptible

        - What's the difference?
            msleep sets the current task to TASK_UNINTERRUPTIBLE
            whereas msleep_interruptible sets the current task to
            TASK_INTERRUPTIBLE before scheduling the sleep. In
            short, the difference is whether the sleep can be ended
            early by a signal. In general, just use msleep unless
            you know you have a need for the interrupt

Angepasst von dieser großartigen Antwort: https://stackoverflow.com/a/39921020/895245

Sehen Sie sich als Nächstes den Dokumentationskommentar zu jeder dieser Funktionen in der Quelle an. Z.B: usleep_range:

 * usleep_range - Sleep for an approximate time
 * @min: Minimum time in usecs to sleep
 * @max: Maximum time in usecs to sleep
 * In non-atomic context where the exact wakeup time is flexible, use
 * usleep_range() instead of udelay().  The sleep improves responsiveness
 * by avoiding the CPU-hogging busy-wait of udelay(), and the range reduces
 * power usage by allowing hrtimers to take advantage of an already-
 * scheduled interrupt instead of scheduling a new one just for this sleep.
void __sched usleep_range(unsigned long min, unsigned long max)

LDD3 7.3. Ausführung verzögern
ist eine weitere unverzichtbare Ressource.

Minimal lauffähige Beispiele

Schreiben Sie endlich Ihre eigenen Minimaltests, um sie auszuprobieren!

#include <linux/delay.h> /* usleep_range */
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/module.h>


static struct task_struct *kthread;

static int work_func(void *data)
    int i = 0;
    while (!kthread_should_stop()) {
        printk(KERN_INFO "%d\n", i);
        usleep_range(1000000, 1000001);
        if (i == 10)
            i = 0;
    return 0;

int init_module(void)
    kthread = kthread_create(work_func, NULL, "mykthread");
    return 0;

void cleanup_module(void)
    /* Waits for thread to return. */

GitHub Upstream.

1389730cookie-checkWie im Linux-Kernel schlafen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy