-
Notifications
You must be signed in to change notification settings - Fork 171
/
realtime-linux-configuration.tex
112 lines (103 loc) · 4.88 KB
/
realtime-linux-configuration.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
\section{Configuring the system}
\begin{frame}
\frametitle{Configuration}
\begin{itemize}
\item The Linux Kernel has a lot of available configurations
\item Some are dedicated to performance
\begin{itemize}
\item Focus on improving the most-likely scenario
\item Have the best average performance
\item Optimize throughput and low-latency
\item Usually have a slow-path, which is non-deterministic
\end{itemize}
\item Some are dedicated to security and hardening
\item Some can be useful for Deterministic Behaviour
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{CPU Pinning}
\begin{itemize}
\item The Linux Kernel Scheduler allows setting constraints about the CPU cores that are allowed
to run each task
\item This can be useful for lots of purposes :
\begin{itemize}
\item Make sure that a process won't be migrated to another core
\item Dedicate cores for specific tasks
\item Optimize the data-path if a process deals with data handled by a specific CPU core
\item Ease the job of the scheduler's CPU load-balancer, whose complexity grows non-linearly with the number of CPUs
\end{itemize}
\item This mechanism is called the \code{cpu affinity} of a process
\item The \code{cpuset} subsystem and the \code{sched_setaffinity} syscall are used to select the CPUs
\item Use \code{taskset -p <mask> <cmd>} to start a new process on the given CPUs
\end{itemize}
\end{frame}
% isolcpus
\begin{frame}
\frametitle{CPU Isolation}
\begin{itemize}
\item Users can pin processes to CPU cores through the cpu affinity mechanism
\item But the kernel might also schedule other processes on these CPUs
\item \code{isolcpus} can be passed on the kernel commandline
\item Isolated CPUs will not be used by the scheduler
\item The only way to run processes on these CPUs is with cpu affinity
\item Very useful when RT processes coexist with non-RT processes
\end{itemize}
\code{isolcpus=0,2,3}
\end{frame}
% irq assignment
\begin{frame}
\frametitle{IRQ affinity}
\begin{itemize}
\item Interrupts are handled by a specific CPU core
\item The default CPU that handles interrupts is the CPU 0
\item On Multi-CPU systems, it can be good to balance interrupt handling between CPUs
\item Similarly, we might also want to prevent CPUs from handling external interrupts
\item IRQs can be pinned to CPUs by tweaking \code{/proc/irq/XX/smp_affinity}
\item The \code{irqbalance} tool monitors and distributes the irq affinty to spread the load across CPUs
\item Use the \code{IRQBALANCE_BANNED_CPUS} environment variable to make \code{irqbalance} ignore some CPUs
\end{itemize}
\end{frame}
% scheduling classes
\input{../common/scheduling-classes.tex}
\begin{frame}
\frametitle{Realtime policies and CPU hogging}
\begin{itemize}
\item A bug or an infinite loop in a high-priority realtime task will cause the system to become unresponsive
\item This can be prevented by creating an emergency shell with a higher priority to kill the faulty programs
\item The Kernel also provides a mechanism to make sure non-RT tasks get to run at one point
\item \code{/proc/sys/kernel/sched_rt_period_us} defines a window in microseconds that the scheduler will share between RT and non-RT tasks
\item \code{/proc/sys/kernel/sched_rt_runtime_us} defines how-much of that window is going to be dedicated to RT tasks.
\item The default values allocates 95\% of the CPU time to RT tasks
\end{itemize}
\end{frame}
% System ticks and NOHZ
\begin{frame}
\frametitle{System timer}
\begin{itemize}
\item The Scheduler is invoked on a regular basis to perform time-sharing activities
\item This is sequenced through the \textbf{system ticks}, generated by a high resolution timer
\item Typically run at 250 Hz (x86) or 100 Hz (arm), but can be configured
\item Several policies regarding system ticks are available :
\item \kconfig{CONFIG_HZ_PERIODIC} : Always tick at a given rate. This can introduce small latencies but keep the system responsive.
\item \kconfig{CONFIG_NO_HZ_IDLE} : Disable the tick when idle, for powersasving
\item \kconfig{CONFIG_NO_HZ_FULL} : Actively disables ticking even when not idle. Introduces long latencies during context switches.
\end{itemize}
\end{frame}
% Memory management and allocators
% Writing a driver
\begin{frame}
\frametitle{Writing a driver}
A few considerations can be taken when writing a driver
\begin{itemize}
\item Avoid using \ksym{raw_spinlock_t} unless really necessary
\item Avoid forcing non-threaded interrupts, unless writing a driver involved in interrupt dispatch
\begin{itemize}
\item irqchip, gpio-irq drivers
\item cpufreq and cpuidle drivers due to scheduler interaction
\end{itemize}
\item Beware of DMA bus mastering and other serialized IO buffering
\begin{itemize}
\item Certain register writes are buffered until the next register read
\end{itemize}
\end{itemize}
\end{frame}