[PATCH v3 0/2] allow creating thread with real-time priority
Stephen Hemminger
stephen at networkplumber.org
Thu Oct 26 23:10:48 CEST 2023
On Thu, 26 Oct 2023 21:55:24 +0200
Thomas Monjalon <thomas at monjalon.net> wrote:
> > To be safe the sleep has to be longer than the system clock tick.
> > Most systems are built today with HZ=250 but really should be using HZ=1000
> > on modern CPU's.
>
> If it has to be more than 1 ms,
> we should mention it is a slow call
> which may be skipped if the thread is already blocking on something else.
A thread that is real time is not subject to timer slack.
Therefore even 100ns would probably work fine.
https://man7.org/linux/man-pages/man7/time.7.html
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 looking at the "resolution" entries in
/proc/timer_list.
HRTs are not supported on all hardware architectures. (Support
is provided on x86, ARM, and PowerPC, among others.)
...
Timer slack
Since Linux 2.6.28, it is possible to control the "timer slack"
value for a thread. The timer slack is the length of time by
which the kernel may delay the wake-up of certain system calls
that block with a timeout. Permitting this delay allows the
kernel to coalesce wake-up events, thus possibly reducing the
number of system wake-ups and saving power. For more details,
see the description of PR_SET_TIMERSLACK in prctl(2).
...
https://man7.org/linux/man-pages/man2/prctl.2.html
PR_SET_TIMERSLACK (since Linux 2.6.28)
Each thread has two associated timer slack values: a
"default" value, and a "current" value. This operation
sets the "current" timer slack value for the calling
thread. arg2 is an unsigned long value, then maximum
"current" value is ULONG_MAX and the minimum "current"
value is 1. If the nanosecond value supplied in arg2 is
greater than zero, then the "current" value is set to this
value. If arg2 is equal to zero, the "current" timer
slack is reset to the thread's "default" timer slack
value.
The "current" timer slack is used by the kernel to group
timer expirations for the calling thread that are close to
one another; as a consequence, timer expirations for the
thread may be up to the specified number of nanoseconds
late (but will never expire early). Grouping timer
expirations can help reduce system power consumption by
minimizing CPU wake-ups.
The timer expirations affected by timer slack are those
set by select(2), pselect(2), poll(2), ppoll(2),
epoll_wait(2), epoll_pwait(2), clock_nanosleep(2),
nanosleep(2), and futex(2) (and thus the library functions
implemented via futexes, including
pthread_cond_timedwait(3), pthread_mutex_timedlock(3),
pthread_rwlock_timedrdlock(3),
pthread_rwlock_timedwrlock(3), and sem_timedwait(3)).
Timer slack is not applied to threads that are scheduled
under a real-time scheduling policy (see
sched_setscheduler(2)).
When a new thread is created, the two timer slack values
are made the same as the "current" value of the creating
thread. Thereafter, a thread can adjust its "current"
timer slack value via PR_SET_TIMERSLACK. The "default"
value can't be changed. The timer slack values of init
(PID 1), the ancestor of all processes, are 50,000
nanoseconds (50 microseconds). The timer slack value is
inherited by a child created via fork(2), and is preserved
across execve(2).
Since Linux 4.6, the "current" timer slack value of any
process can be examined and changed via the file
/proc/pid/timerslack_ns. See proc(5).
More information about the dev
mailing list