How preemption works on Linux when a program has a timer less then 4ms?

Jiffies in most Linux system are defaulted to 250 (4ms). The questions is that what happens when a program has a usleep() less then 4ms ? Of course it works as should when it is scheduled. But what happens when linux scheduler takes out this program to wait, because another program has to operate ? How does the preemption works in this case?

Should I avoid custom programs with such a small waiting? They couldn’t be accurate, could it ?

Asked By: roncsak

||

Unless you’re running a realtime kernel, I wouldn’t use sleep times < 10ms anyway tbh. Even if the scheduler is willing to pre-empt another process for your timeout, jitter will probably dominate your actual sleep times.

Summary: avoid such small intervals unless you have a realtime kernel.
If you can’t change kernel, your best bet may be to pin your process to a dedicated CPU with SCHED_FIFO and busy-wait (or do other useful work) for anything less than about two jiffies.

Somehow the summary ended up longer than the original … oh well.

Answered By: Useless

See time(7), and the manpages it references. An excerpt:

High-Resolution Timers
   Before Linux 2.6.21, the accuracy of timer and sleep system calls  (see
   below) was also limited by the size of the jiffy.

   Since  Linux  2.6.21,  Linux  supports  high-resolution  timers (HRTs),
   optionally configurable via CONFIG_HIGH_RES_TIMERS.  On a  system  that
   supports  HRTs,  the  accuracy  of  sleep  and timer system calls is no
   longer constrained by the jiffy, but instead can be as accurate as  the
   hardware  allows  (microsecond accuracy is typical of modern hardware).
   You can determine  whether  high-resolution  timers  are  supported  by
   checking  the resolution returned by a call to clock_getres(2) or look‐
   ing at the "resolution" entries in /proc/timer_list.

   HRTs are not supported on all hardware architectures.  (Support is pro‐
   vided on x86, arm, and powerpc, among others.)

A comment suggests that you can’t sleep less than a jiffy. That is incorrect; with HRTs, you can. Try this program:

/* test_hrt.c */
#include <time.h>
main()
{
        struct timespec ts;
        int i;

        ts.tv_sec = 0;
        ts.tv_nsec = 500000;  /* 0.5 milliseconds */
        for (i = 0; i < 1000; i++) {
                clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL);
        }
}

Compile it:

$ gcc -o test_hrt test_hrt.c -lrt

Run it:

$ time ./test_hrt

real    0m0.598s
user    0m0.008s
sys     0m0.016s

As you can see, 1000 iterations of a 0.5 millisecond delay took just a little over 0.5 seconds, as expected. If clock_nanosleep were truly waiting until the next jiffy before returning, it would have taken at least 4 seconds.


Now the original question was, what happens if your program was scheduled out during that time? And the answer is that it depends on the priority. Even if another program gets scheduled while your program is running, if your program is higher priority, or the scheduler decides that it’s your program’s time to run, it will start executing again after the clock_nanosleep timeout returns. It does not need to wait until the next jiffy for that to happen. You can try running the test program above while running other software that takes the CPU, and you’ll see that it still executes in the same amount of time, especially if you increase the priority with e.g.

$ time sudo schedtool -R -p 99 -e ./test_hrt
Answered By: Jim Paris
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.