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