From nobody Tue Dec 2 02:06:11 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECE71302150; Thu, 20 Nov 2025 11:37:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638636; cv=none; b=Mhf/Rhf/PoyVWFaUORkR515U/18UPM9qnJwKpraZ442ewIzWsELLZRTXs5cg0uQWncwUV7JZOxODKPF5d/Khzx0Nz3DDGq4MbHj2eWb35JrTY6O0yvOvE+xHw8oFLyOE1cngRKG3lb65RLYnxYA1b5ymkTOm2H8kCrHDR8+EXWo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638636; c=relaxed/simple; bh=fZNKUQsFVE1t1uphqz9t0AoQUDH/JdNpi8q7/61pQbQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=M5gjXOogQUGRnP/szGSYKO1hMyGIVuErig1bMuEZoXq0UrmmPV2noUk+ghxflRt2+N2lznLcw1uOqlta13QvOQ5fmT2GuYRffjlugmyZEq81uJr4cfSzI+DKytXIsOPpk7vntO6tzE1BTDrAMA/op/Nx5uGzSswX2SOYX1wWRQA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Qhfr00GD; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=gCe5WVxc; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Qhfr00GD"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="gCe5WVxc" From: Sebastian Andrzej Siewior DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763638633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PTLRfnMKknqj+tCmpvzA6teeIrR7xMPQdDGiPXPUVAE=; b=Qhfr00GDHiwZakzfBr/GxmO+GxOHJ/UgTMgbsPGvZFkmmaOmHt/gitMB0pDlWvG9oc4BOD J1PEy8kaUdTYwxIUxRMo4r9WPPmATeK4uMi5RxKYnKtYIwB9Tp8AsIz7ak5dPGahtEcOKJ cTMAgtUk57Wiqq5IPHZSKmxjOjLNs951N0p07dsqT44T+kEvI+8Ecv7hwueLgBnQxua2LQ A4l2UD7s2WJl2qOxupAtmyssAEuxS7yEQVBDKLulXo5d+hmqDRVXTQDLdUHuafnhR+o9IB VuIAscAQipf+bpAQRxSkH74pQGH5yRgcZdIOLZGT3v402zOtJnYTVtb4zJqoCQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763638633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PTLRfnMKknqj+tCmpvzA6teeIrR7xMPQdDGiPXPUVAE=; b=gCe5WVxcahTG5x7rH8p4FgypS82DhbbSwzaeRev6C7DE5MO4XxvdDCErEQdkfAc+SLtKgI iTcQ6R2BQAhxo9CA== To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Cc: Clark Williams , John Ogness , Jonathan Corbet , Steven Rostedt , Sebastian Andrzej Siewior Subject: [PATCH 1/3] Documentation: Add some hardware hints for real-time Date: Thu, 20 Nov 2025 12:37:06 +0100 Message-ID: <20251120113708.83671-2-bigeasy@linutronix.de> In-Reply-To: <20251120113708.83671-1-bigeasy@linutronix.de> References: <20251120113708.83671-1-bigeasy@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Some thoughts on hardware that is used for real-time workload. Certainly not complete but should cover some of the import topics such as: - Main memory, caches and the possiblie control given by the hardware. - What could happen by putting critical hardware behind USB or VirtIO. - Allowing real-time tasks to consume the CPU entirely without giving the system some time to breath. - Networking with what the kernel provides. Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Randy Dunlap Reviewed-by: Steven Rostedt (Google) --- Documentation/core-api/real-time/hardware.rst | 132 ++++++++++++++++++ Documentation/core-api/real-time/index.rst | 1 + 2 files changed, 133 insertions(+) create mode 100644 Documentation/core-api/real-time/hardware.rst diff --git a/Documentation/core-api/real-time/hardware.rst b/Documentation/= core-api/real-time/hardware.rst new file mode 100644 index 0000000000000..57e9191cca640 --- /dev/null +++ b/Documentation/core-api/real-time/hardware.rst @@ -0,0 +1,132 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Considering hardware +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +:Author: Sebastian Andrzej Siewior + +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 ano= ther +task to wait until a cache line is written back to main memory before it c= an +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 patte= rns +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 C= PU +cache. The kernel is aware of the cache topology and exports this informat= ion to +user space. Tools such as **lstopo** from the Portable Hardware Locality (= hwloc) +project (https://www.open-mpi.org/projects/hwloc/) can visualize the hiera= rchy. + +Avoiding shared L2 or L3 caches is not always possible. Even when cache sh= aring +is minimized, bottlenecks can still occur when accessing system memory. Me= mory +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 hardw= are +provides the necessary support. On x86 systems, Intel offers Cache Allocat= ion +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 interf= ace. +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 busses +--------------- + +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 o= f the +task. For example, on an I/O bus, a changed output may not become immediat= ely +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 stal= ls the +CPU until the device responds. + +A bus such as USB is more complex, involving multiple layers. A register r= ead +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 +underlying USB bus. Requests cannot be sent immediately; they must align w= ith +the next frame boundary according to the endpoint type and the host contro= ller's +scheduling rules. This can introduce delays and additional latency. For ex= ample, +a network device connected via USB may still deliver sufficient throughput= , but +the added latency when sending or receiving packets may fail to meet the +requirements of certain real-time use cases. + +Additional restrictions on bus latency can arise from power management. For +instance, PCIe with Active State Power Management (ASPM) enabled can suspe= nd +the link between the device and the host. While this behavior is beneficia= l for +power savings, it delays device access and adds latency to responses. This= issue +is not limited to PCIe; internal buses within a System-on-Chip (SoC) can a= lso be +affected by power management mechanisms. + +Virtualization +-------------- + +In a virtualized environment such as KVM, each guest CPU is represented as= a +thread on the host. If such a thread runs with real-time priority, the sys= tem +should be tested to confirm it can sustain this behavior over extended per= iods. +Because of its priority, the thread will not be preempted by lower-priority +threads (such as SCHED_OTHER), which may then receive no CPU time. This can +cause problems if a lower-priority thread is pinned to a CPU already occup= ied by +a real-time task and unable to make progress. Even if a CPU has been isola= ted, +the system may still (accidentally) start a per=E2=80=91CPU thread on that= CPU. +Ensuring that a guest CPU goes idle is difficult, as it requires avoiding = both +task scheduling and interrupt handling. Furthermore, if the guest CPU does= go +idle but the guest system is booted with the option **idle=3Dpoll**, the g= uest +CPU will never enter an idle state and will instead spin until an event +arrives. + +Device handling introduces additional considerations. Emulated PCI devices= or +VirtIO devices require a counterpart on the host to complete requests. This +adds latency because the host must intercept and either process the request +directly or schedule a thread for its completion. These delays can be avoi= ded if +the required PCI device is passed directly through to the guest. Some devi= ces, +such as networking or storage controllers, support the PCIe SR-IOV feature. +SR-IOV allows a single PCIe device to be divided into multiple virtual fun= ctions, +which can then be assigned to different guests. + +Networking +---------- + +For low-latency networking, the full networking stack may be undesirable, = as it +can introduce additional sources of delay. In this context, XDP can be used +as a shortcut to bypass much of the stack while still relying on the kerne= l's +network driver. + +The requirements are that the network driver must support XDP- preferably = using +an "skb pool" and that the application must use an XDP socket. Additional +configuration may involve BPF filters, tuning networking queues, or config= uring +qdiscs for time-based transmission. These techniques are often +applied in Time-Sensitive Networking (TSN) environments. + +Documenting all required steps exceeds the scope of this text. For detailed +guidance, see the TSN documentation at https://tsn.readthedocs.io. + +Another useful resource is the Linux Real-Time Communication Testbench +https://github.com/Linutronix/RTC-Testbench. +The goal of this project is to validate real-time network communication. I= t can +be thought of as a "cyclictest" for networking and also serves as a starti= ng +point for application development. diff --git a/Documentation/core-api/real-time/index.rst b/Documentation/cor= e-api/real-time/index.rst index 7e14c4ea3d592..f08d2395a22c9 100644 --- a/Documentation/core-api/real-time/index.rst +++ b/Documentation/core-api/real-time/index.rst @@ -13,4 +13,5 @@ the required changes compared to a non-PREEMPT_RT configu= ration. =20 theory differences + hardware architecture-porting --=20 2.51.0 From nobody Tue Dec 2 02:06:11 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 816E4313E3F; Thu, 20 Nov 2025 11:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638637; cv=none; b=SE0YyCzBdsoPxm/1xl9OI5nuKP4jqDvIXvn636alXYMz+xv6PXeSyiaF7vNv8XzSbBXqbHTvJeT7JCBjkJCob+4hgO04RTcslINjmb0HIbuEqAb7Skb+2CEM9vf8orFS4uPJB1BIwZ91vy9VQWIu6ltBCpziY9hVjCUI9IZxETY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638637; c=relaxed/simple; bh=u6h3ZNUO0zoQExnRRWoer+eeLxLu9lBenh5UGVbqZRo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YJoS65Nyselo+4PafTVbEC6a2Yb4gs6aN+3SJyTthXWGZZhA6o2sy4WmWyM1pp+Vv5txG+/ZW5/D4pUclGIVgZBm9PNXQagppk3IBECl/uaxHLHxTwIDN+TWTAEgn9sP+gXH7GN0xRMqR1aOTnR4JsGC/PQHxYugm2u3IhZ9I3c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=d9BbKUOC; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=1GcPyv+o; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="d9BbKUOC"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="1GcPyv+o" From: Sebastian Andrzej Siewior DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763638633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j0s+KZLerg4BQqOc+D0EnISDSeG6auMMoaePFrnQ7vg=; b=d9BbKUOCrhqNNIXBfPVaxQBly+gRXj0D5F8vGnZxC8A15sPvM2eIisQKgXW53uSqjRwg7W TFyPBo8TZ/xyzZYSl1Ghn3RjMfoC6bAZsZvVKzO0rvu11YaNuLxlD+iGPoyaLOG9V0LGbq cyKRJ9WvEj3KO6x70XI+PM9IinEy60Tpz9pZ6Kl50uJQRf4V3QaGtOdBEkf3+oTuLCPFjb 9wguuVmooig94tsI0vfjXXvia4Z/rixlaSBriZ3fjtdxipjCr6sJhdjvbvrO/RJpYof1Tn isurdtiEk/dy+8B4IvOpqV1yWvmctbFSD5LLFR5VpyOZ5zuD2x+ml1Ao+QXCQg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763638633; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j0s+KZLerg4BQqOc+D0EnISDSeG6auMMoaePFrnQ7vg=; b=1GcPyv+ouFXJM4QnwIDSrVtfTqP1RP0MLaeDXfXAlkriFtYN1wP17YVQ8obCexZViZriI+ ywWB7RegZcISFyCw== To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Cc: Clark Williams , John Ogness , Jonathan Corbet , Steven Rostedt , Lukas Bulwahn , Sebastian Andrzej Siewior Subject: [PATCH 2/3] Documentation: update config name in real-time architecture support Date: Thu, 20 Nov 2025 12:37:07 +0100 Message-ID: <20251120113708.83671-3-bigeasy@linutronix.de> In-Reply-To: <20251120113708.83671-1-bigeasy@linutronix.de> References: <20251120113708.83671-1-bigeasy@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lukas Bulwahn Commit 4843a45ef9fe8 ("entry: Rename "kvm" entry code assets to "virt" to genericize APIs") renames the config KVM_XFER_TO_GUEST_WORK to VIRT_XFER_TO_GUEST_WORK. Adjust the documentation to the current situation, and specifically refer to the new name of the config. Signed-off-by: Lukas Bulwahn Signed-off-by: Sebastian Andrzej Siewior --- Documentation/core-api/real-time/architecture-porting.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/core-api/real-time/architecture-porting.rst b/Do= cumentation/core-api/real-time/architecture-porting.rst index d822fac29922d..c90a426d80624 100644 --- a/Documentation/core-api/real-time/architecture-porting.rst +++ b/Documentation/core-api/real-time/architecture-porting.rst @@ -35,7 +35,8 @@ POSIX CPU timers and KVM POSIX CPU timers must expire from thread context rather than directly wi= thin the timer interrupt. This behavior is enabled by setting the configurati= on option CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK. - When KVM is enabled, CONFIG_KVM_XFER_TO_GUEST_WORK must also be set to e= nsure + When virtualization support, such as KVM, is enabled, + CONFIG_VIRT_XFER_TO_GUEST_WORK must also be set to ensure that any pending work, such as POSIX timer expiration, is handled before transitioning into guest mode. =20 --=20 2.51.0 From nobody Tue Dec 2 02:06:11 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D4A22ECEA3; Thu, 20 Nov 2025 11:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638637; cv=none; b=pGDiyc0LPzCVPudUtf0plK3RCNkZ/xKjp9kc9a6IgK/VZeyH2QecY5M4++Dw7FX0YZ6Yx/5CPp7mp3TmO2UrNj3LGaX7gTnHJPW49xlNzQT/GMBO7ZW9cmBExMYfYGcRhbOPFCGTqsMXdhSbiUBxtH8yqfTO1mD4yEHYXfZBcU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763638637; c=relaxed/simple; bh=n4xhlXgGFxvyLf4Y2Uwo0aMLHx0Nalo6k0hY2mRFNU0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V89BGbHfOnfebnJyBtQpIlxNjVRqrakdVekMh5LXY9F7o4fItlTuKAKtELalfDJniE3dCcf4Fb9cXnwK6cIDQZTGVidtbJpItxGLHJnl0z1t3ElF51CDgbzCcbXntOSidUJOHFn+kIM7XfldtDYBVTFx+37Lf8A5aG/C5YSfZgE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=OYaeRMev; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=E4zINMLa; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="OYaeRMev"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="E4zINMLa" From: Sebastian Andrzej Siewior DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763638634; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Z7FbmHbPk7jlB4aC3UbKjF1UgKb17UqpSn//sPlqco=; b=OYaeRMevtzcMJQNHDO95JCITv9ovyMBu3t9V/i2AUNtefmYItF1QkskQVu9NzaPOvTYK9b rqn6WRK3qDq59MlgM7BRBAnx9hPwdqmIgMGBlI3tOQfQCkq6Gk+GDVe/L/Me8OW1dWkR/7 saVmXtuzMpk1F40uQz1bVdzsgQyi+hVPc6Y7oqWkdf3iCWCmtjPtUPd+YIymgQ41pb+znw R6wuSxxHxWk++zR9jl8hOo9GoBM+9VJKqBlZyi03z326biT9kHCJlgcflTK+Mj3UMMbBRe 3WvG2n5phvK8ZWx8zrmokDKgzs15B+uo99n2/IGyBehhLhyateY4dqKG1SppzQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763638634; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Z7FbmHbPk7jlB4aC3UbKjF1UgKb17UqpSn//sPlqco=; b=E4zINMLaAUxamLdzpLh+Eg2h2juGcwhfMN3Ysq+I0uTfRia3cM11fgMWAwztSo8dzMVaCk mwDjMpIY9V8MEODg== To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev Cc: Clark Williams , John Ogness , Jonathan Corbet , Steven Rostedt , Lukas Bulwahn , Sebastian Andrzej Siewior Subject: [PATCH 3/3] MAINTAINERS: Add doc files on real-time support to Real-time Linux Date: Thu, 20 Nov 2025 12:37:08 +0100 Message-ID: <20251120113708.83671-4-bigeasy@linutronix.de> In-Reply-To: <20251120113708.83671-1-bigeasy@linutronix.de> References: <20251120113708.83671-1-bigeasy@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lukas Bulwahn Commit f51fe3b7e48c ("Documentation: Add real-time to core-api") adds new documentation on real-time support, i.e., PREEMPT_RT. So, add a file entry for that directory to the corresponding section in MAINTAINERS. Signed-off-by: Lukas Bulwahn Signed-off-by: Sebastian Andrzej Siewior --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 836ec73c604d6..a98668acce039 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -21823,6 +21823,7 @@ M: Clark Williams M: Steven Rostedt L: linux-rt-devel@lists.linux.dev S: Supported +F: Documentation/core-api/real-time/ K: PREEMPT_RT =20 REALTEK AUDIO CODECS --=20 2.51.0