realtime:documentation:howto:tools:cpu-partitioning:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
realtime:documentation:howto:tools:cpu-partitioning:start [2024/05/20 01:20] alison [Softirqs and kthreads] |
realtime:documentation:howto:tools:cpu-partitioning:start [2024/05/27 01:18] alison [Realtime application best practices] |
||
|---|---|---|---|
| Line 82: | Line 82: | ||
| ==== Housekeeping cores ==== | ==== Housekeeping cores ==== | ||
| - | A common paradigm with realtime systems is to pin latency-insensitive kernel and userspace tasks tasks on a designated "housekeeping" core. For example, //taskset// can pin kernel threads like //kswapd// and //kauditd//. Applications whose network traffic latency is not critical may wish to pin network IRQs there as well. Userspace threads which are sometimes CPU-intensive like systemd and rsyslog may also be pinned on the housekeeping core. Pinning userspace threads may not have the desired effect if much of their work is performed by [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cpu-partitioning/start#cpu_affinity_and_kworkers|unbound workqueues]], which may migrate to any core. | + | A common paradigm with realtime systems is to pin latency-insensitive kernel and userspace tasks tasks on a designated "housekeeping" core. For example, //taskset// can pin kernel threads like //kswapd// and //kauditd//. Applications whose network traffic latency is not critical may wish to pin network IRQs there as well. Userspace threads which are sometimes CPU-intensive like systemd and rsyslog may also be pinned on the housekeeping core. Pinning userspace threads will not have the desired effect if much of their work is performed by [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cpu-partitioning/start#cpu_affinity_and_kworkers|unbound workqueues]], which may migrate to any core. |
| ==== Softirqs and kthreads ==== | ==== Softirqs and kthreads ==== | ||
| Line 89: | Line 89: | ||
| Kernel configuration allows system managers to move the NET_RX and RCU callbacks out of softirqs and into their own kthreads. Since kernel 5.12, moving the NET_RX into its own kthread is possible by //echo//-ing '1' into the //threaded// sysfs attribute associated with a network device. The process table will afterwards include a new kthread called //napi/xxx//, where xxx is the interface name. [Read more about the [[https://wiki.linuxfoundation.org/networking/napi?s[]=napi|NAPI]] mechanism in the networking wiki.] Userspace may employ //taskset// to pin this kthread on any core. Moving the softirq into its own kthread incurs a context-switch penalty, but even so may be worthwhile on systems where bursts of network traffic unacceptably delay applications. [[https://wiki.linuxfoundation.org/realtime/documentation/technical_details/rcu?s[]=rcu#rcu_callback_offloading|RCU Callback Offloading]] produces a new set of kthreads, and can be accomplished via a combination of compile-time configuration with boot-time command-line parameters. | Kernel configuration allows system managers to move the NET_RX and RCU callbacks out of softirqs and into their own kthreads. Since kernel 5.12, moving the NET_RX into its own kthread is possible by //echo//-ing '1' into the //threaded// sysfs attribute associated with a network device. The process table will afterwards include a new kthread called //napi/xxx//, where xxx is the interface name. [Read more about the [[https://wiki.linuxfoundation.org/networking/napi?s[]=napi|NAPI]] mechanism in the networking wiki.] Userspace may employ //taskset// to pin this kthread on any core. Moving the softirq into its own kthread incurs a context-switch penalty, but even so may be worthwhile on systems where bursts of network traffic unacceptably delay applications. [[https://wiki.linuxfoundation.org/realtime/documentation/technical_details/rcu?s[]=rcu#rcu_callback_offloading|RCU Callback Offloading]] produces a new set of kthreads, and can be accomplished via a combination of compile-time configuration with boot-time command-line parameters. | ||
| - | ===== Realtime application example ===== | + | ===== Realtime application best practices ===== |
| - | + | ||
| - | FIXME and fill it with content. | + | |
| + | Multithreaded applications which rely on glibc's libpthread are prone to unexpected latency delays since pthread condition variables do not honor priority inheritance ([[https://sourceware.org/bugzilla/show_bug.cgi?id=11588|bugzilla]]). [[https://github.com/dvhart/librtpi|librtpi]] is an alternative LGPL-licensed pthread implementation which supports priority inheritance, and whose API as close to glibc's as possible. The alternative [[https://www.musl-libc.org/|MUSL libc's pthread implementation]] appears to be similar to glibc's. | ||
realtime/documentation/howto/tools/cpu-partitioning/start.txt · Last modified: 2024/05/27 23:33 by alison
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
