Re: [PATCH v5 1/1] Documentation: real-time: Add kernel configuration guide

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Typographical errors in the documentation text and the commit message.
--

--- Patch [1]: [PATCH v5 1/1] Documentation: real-time: Add kernel configuration guide ---
commit fc9a84c888f9e6c7081f477ffb83f1ff5bc1b0aa
Author: Ahmed S. Darwish <darwi@linutronix.de>

Documentation: real-time: Add kernel configuration guide
    
This commit adds a new kernel configuration guide for real-time systems,
detailing recommended Kconfig options. It lists options for CPU governors,
cpuidle, graphics, EFI, NO_HZ, and debugging features, explaining the
latency impacts for each.

> Add a summary at the end of the document warning users that there is a no
> "one size fits all solution" for configuring a real-time system.

[Severity: Low]
This isn't a bug, but there is a typo in the commit message: "a no"
should probably just be "no".

> diff --git a/Documentation/core-api/real-time/kernel-configuration.rst b/Documentation/core-api/real-time/kernel-configuration.rst
> new file mode 100644
> index 0000000000000..72f7e8453bcc5
> --- /dev/null
> +++ b/Documentation/core-api/real-time/kernel-configuration.rst
> @@ -0,0 +1,307 @@

[ ... ]

> +Non-performance CPU frequency governors
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +:Expectation: disabled
> +:Severity: *medium*
> +
> +To ensure reproducible system latency measurements, disable the
> +non-``PERFORMANCE`` CPU frequency governors whenever possible.  This avoids
> +the risk of unknown userspace tasks implicitly or explicitly setting a
> +different CPU frequency governor, and and thereby changing latency behavior
> +while the system is running.

[Severity: Low]
This isn't a bug, but there is a duplicated "and" in the sentence above.

[ ... ]

> +``CONFIG_TRACING`` (and tracing options)
> +----------------------------------------
> +
> +:Expectation: enabled
> +:Severity: *info*
> +
> +Shipping kernels with tracing support enabled (but not actively running) is
> +highly recommended.  This will allow the users to extract more information if
> +latency problems arise.  Nonetheless, some tracers do incur latency overhead
> +by just being enable.

[Severity: Low]
This isn't a bug, but "enable" here should probably be "enabled".

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804133746.744212-2-darwi@linutronix.de?part=1