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

["Ahmed S. Darwish" <darwi@linutronix.de>]

On Tue, 21 Jul 2026, Sebastian Andrzej Siewior wrote:
>
> On 2026-07-16 21:57:14 [+0200], Ahmed S. Darwish wrote:
> > +``CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE``
> > +-------------------------------------------
> > +
> > +:Expectation: enabled
> > +:Severity: *high*
> > +
> > +Real-Time workloads expect a fixed CPU frequency during execution.  Using
> > +the performance governor is an easy way to achieve that purely from kernel
> > +configuration.
> > +
> > +This is not a blanket rule.  Some setups might prefer to clock the CPU to
> > +lower speeds due to thermal packaging or other requirements.  The key is
> > +that the CPU frequency remains constant once set.
>
> A dynamic governor such as CONFIG_CPU_FREQ_GOV_POWERSAVE must be
> avoided.
>

ACK.

>
> > …
> > +
> > +- :doc:`Regarding hardware (System memory and cache) </core-api/real-time/hardware>`
> > +- :doc:`/filesystems/resctrl`>
>
> I've been told by Jonathan to avoid this and just use plain file
> references such as
> - Documentation/admin-guide/pm/cpuidle.rst
> - Documentation/admin-guide/pm/index.rst
>

ACK.

> > +- `Real-Time and Graphics: A Contradiction?`_
>
> And this might be included inline, too.
>
> > +``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 enabled; see :ref:`tracers`.
>
> Instead of this jumping forth and back while reading, couldn't the
> CONFIG_IRQSOFF_TRACER and CONFIG_PREEMPT_TRACER be added here?
>

I'll think of something.

> >
> > +Non-performance CPU frequency governors
> > +---------------------------------------
>
> so here it is.
> > …
> > …
>
> Could we please merge this in the previous section so that we don't have
> two times the CPU frequency governors.
>

OK.

>
> Could we merge the caution box from before here somehow? The statement
> is that lockdep is very helpful in validating lockchains and so on
> especially on paths which are only seen if the real-time workload is
> active. However, since it can easily introduce scheduling latencies of
> 10ms it is hardly an option that ca be enabled in production.
>

I'll think of something.

> > +
> > +``CONFIG_DEBUG_FS``
> > +^^^^^^^^^^^^^^^^^^^
> > +
> > +This is safe to include in real-time kernels, *provided that debugfs is
> > +not accessed during production runtime*.
>
> It is safe to have as long as you don't use it.

which is what I said above.

>
> I would drop it.
>

Well, earlier I stated that debug options need to be disabled for a
real-time kernel, except the explicitly list debug options which are deemed
OK.  So I need to mention that CONFIG_DEBUG_FS is deemed OK.  The list
above is not saying, "enable it for RT".  It rather says, "if you need it,
it's not problematic for RT."

>
> > +
> > +``CONFIG_DEBUG_KERNEL``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Meta-option which allows debug features to be enabled.  This configuration
> > +option has no runtime impact, but be aware of any debug features that it
> > +may have allowed to be enabled.
>
> This one should come first (if at all) because it enables to access of
> few of the options mentioned in this section.
>

All the options are alphabetically listed, so that the 3-level table of
contents on top (which lists all options) is clear and users cannot miss anything.

I'll think about this.

Thanks,
Ahmed