DPDK patches and discussions
 help / color / mirror / Atom feed
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).


  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).