From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "Morten Brørup" <mb@smartsharesystems.com>,
dev@dpdk.org, bruce.richardson@intel.com,
"David Marchand" <david.marchand@redhat.com>
Subject: Re: [PATCH v3 0/2] allow creating thread with real-time priority
Date: Thu, 26 Oct 2023 14:10:48 -0700 [thread overview]
Message-ID: <20231026141048.29c2ff9e@hermes.local> (raw)
In-Reply-To: <2655403.X9hSmTKtgW@thomas>
On Thu, 26 Oct 2023 21:55:24 +0200
Thomas Monjalon <thomas@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).
next prev parent reply other threads:[~2023-10-26 21:10 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 12:54 [PATCH] eal/unix: " Thomas Monjalon
2023-10-24 13:55 ` Morten Brørup
2023-10-24 16:04 ` Stephen Hemminger
2023-10-25 13:15 ` Thomas Monjalon
2023-10-25 13:34 ` Bruce Richardson
2023-10-25 13:44 ` Thomas Monjalon
2023-10-25 15:08 ` Stephen Hemminger
2023-10-25 15:14 ` Bruce Richardson
2023-10-25 15:18 ` Thomas Monjalon
2023-10-25 15:32 ` Thomas Monjalon
2023-10-25 15:13 ` [PATCH v2] " Thomas Monjalon
2023-10-25 15:37 ` Stephen Hemminger
2023-10-25 16:46 ` Thomas Monjalon
2023-10-25 17:54 ` Morten Brørup
2023-10-25 21:33 ` Stephen Hemminger
2023-10-26 7:33 ` Morten Brørup
2023-10-26 16:32 ` Stephen Hemminger
2023-10-26 17:07 ` Morten Brørup
2023-10-26 0:00 ` Stephen Hemminger
2023-10-25 16:31 ` [PATCH v3 0/2] " Thomas Monjalon
2023-10-25 16:31 ` [PATCH v3 1/2] eal: add thread yield functions Thomas Monjalon
2023-10-25 16:40 ` Bruce Richardson
2023-10-25 17:06 ` Thomas Monjalon
2023-10-25 18:07 ` Morten Brørup
2023-10-25 16:31 ` [PATCH v3 2/2] eal/unix: allow creating thread with real-time priority Thomas Monjalon
2023-10-26 13:36 ` [PATCH v3 0/2] " Thomas Monjalon
2023-10-26 13:44 ` Morten Brørup
2023-10-26 13:57 ` Morten Brørup
2023-10-26 14:04 ` Thomas Monjalon
2023-10-26 14:08 ` Morten Brørup
2023-10-26 14:30 ` Thomas Monjalon
2023-10-26 14:50 ` Morten Brørup
2023-10-26 14:59 ` Morten Brørup
2023-10-26 15:54 ` Bruce Richardson
2023-10-26 16:07 ` Thomas Monjalon
2023-10-26 16:50 ` Morten Brørup
2023-10-26 19:51 ` Thomas Monjalon
2023-10-27 7:19 ` Morten Brørup
2023-10-26 16:28 ` Stephen Hemminger
2023-10-26 19:55 ` Thomas Monjalon
2023-10-26 21:10 ` Stephen Hemminger [this message]
2023-10-26 14:10 ` David Marchand
2023-10-26 13:37 ` [PATCH v4 " Thomas Monjalon
2023-10-26 13:37 ` [PATCH v4 1/2] eal: add thread yield functions Thomas Monjalon
2023-10-26 13:37 ` [PATCH v4 2/2] eal/unix: allow creating thread with real-time priority Thomas Monjalon
2023-10-26 14:19 ` [PATCH v5 0/2] " Thomas Monjalon
2023-10-26 14:19 ` [PATCH v5 1/2] eal: add thread yield functions Thomas Monjalon
2023-10-26 14:19 ` [PATCH v5 2/2] eal/unix: allow creating thread with real-time priority Thomas Monjalon
2023-10-26 20:00 ` [PATCH v5 0/2] " Thomas Monjalon
2023-10-26 23:35 ` Tyler Retzlaff
2023-10-27 8:08 ` [PATCH v6 1/1] eal/unix: " Thomas Monjalon
2023-10-27 8:45 ` Morten Brørup
2023-10-27 9:11 ` Thomas Monjalon
2023-10-27 18:15 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231026141048.29c2ff9e@hermes.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).