Documentation/core-api/real-time/hardware.rst

Source file repositories/reference/linux-study-clean/Documentation/core-api/real-time/hardware.rst

File Facts

System
Linux kernel
Corpus path
Documentation/core-api/real-time/hardware.rst
Extension
.rst
Size
7015 bytes
Lines
133
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

====================
Considering hardware
====================

:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

The way a workload is handled can be influenced by the hardware it runs on.
Key components include the CPU, memory, and the buses that connect them.
These resources are shared among all applications on the system.
As a result, heavy utilization of one resource by a single application
can affect the deterministic handling of workloads in other applications.

Below is a brief overview.

System memory and cache
-----------------------

Main memory and the associated caches are the most common shared resources among
tasks in a system. One task can dominate the available caches, forcing another
task to wait until a cache line is written back to main memory before it can
proceed. The impact of this contention varies based on write patterns and the
size of the caches available. Larger caches may reduce stalls because more lines
can be buffered before being written back. Conversely, certain write patterns
may trigger the cache controller to flush many lines at once, causing
applications to stall until the operation completes.

This issue can be partly mitigated if applications do not share the same CPU
cache. The kernel is aware of the cache topology and exports this information to
user space. Tools such as **lstopo** from the Portable Hardware Locality (hwloc)
project (https://www.open-mpi.org/projects/hwloc/) can visualize the hierarchy.

Avoiding shared L2 or L3 caches is not always possible. Even when cache sharing
is minimized, bottlenecks can still occur when accessing system memory. Memory
is used not only by the CPU but also by peripheral devices via DMA, such as
graphics cards or network adapters.

In some cases, cache and memory bottlenecks can be controlled if the hardware
provides the necessary support. On x86 systems, Intel offers Cache Allocation
Technology (CAT), which enables cache partitioning among applications and
provides control over the interconnect. AMD provides similar functionality under
Platform Quality of Service (PQoS). On Arm64, the equivalent is Memory
System Resource Partitioning and Monitoring (MPAM).

These features can be configured through the Linux Resource Control interface.
For details, see Documentation/filesystems/resctrl.rst.

The perf tool can be used to monitor cache behavior. It can analyze
cache misses of an application and compare how they change under
different workloads on a neighboring CPU. Even more powerful, the perf
c2c tool can help identify cache-to-cache issues, where multiple CPU
cores repeatedly access and modify data on the same cache line.

Hardware buses
--------------

Real-time systems often need to access hardware directly to perform their work.
Any latency in this process is undesirable, as it can affect the outcome of the
task. For example, on an I/O bus, a changed output may not become immediately
visible but instead appear with variable delay depending on the latency of the
bus used for communication.

A bus such as PCI is relatively simple because register accesses are routed
directly to the connected device. In the worst case, a read operation stalls the
CPU until the device responds.

A bus such as USB is more complex, involving multiple layers. A register read
or write is wrapped in a USB Request Block (URB), which is then sent by the
USB host controller to the device. Timing and latency are influenced by the

Annotation

Implementation Notes