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

[Ahmed S. Darwish]

On Thu, 05 Mar 2026, Steven Rostedt wrote:
>
> Very nice document!
>

Oh, thanks :)

>
> > +
> > +``CONFIG_PREEMPT_RT`` enables this option by default.  If this option is
> > +disabled during the kernel build, pass the following boot parameter [1]_::
> > +
> > +  efi=noruntime
>
> The above reads a bit funny. Maybe reword it to:
>
>   ``CONFIG_PREEMPT_RT`` enables this option by default. If this option is
>   manually disabled at build time, the following boot parameter [1]_ may
>   be used to disable EFI runtime at boot up::
>
> Or something like that.
>

Yes, much better; will do.

> > +
> > +There is ongoing `development work`_ to allow EFI variables access for a
> > +real-time Linux system.
>
>   .. to allow access to EFI variables for a real-time Linux system
>
>  ?
>

Yup.

> > +``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.
> > +
> > +.. caution::
> > +
> > +  Users should *not* make use of tracers or trace events during production
> > +  real-time kernel operation as they can add considerable overhead and
> > +  degrade the system's latency.
>
> I wonder if a special note should be called out for:
>
>   CONFIG_IRQSOFF_TRACER and CONFIG_PREEMPT_TRACER should be avoided as they
>   do incur measurable overhead even when tracing is not currently active.
>
> Maybe the above should be added in the "Problematic debug options"?
>

Oh, didn't know about that; I'll add them for sure.

>
> > +Kernel Debug Options
> > +====================
> > +
> > +Most kernel debug options add runtime overhead that increases the
> > +worst-case latency.
> > +
> > +.. caution::
> > +
> > +  During development and early testing, users are encouraged to run their
> > +  real-time workloads and peripherals with lockdep and other kernel debug
> > +  options enabled, for a considerable amount of time.  Such workloads
> > +  might trigger kernel code paths that were not triggered during the
> > +  internal Linux real-time kernel development, thus helping to uncover any
> > +  real-time latency issues in the kernel.
>
> Hmm, perhaps there should be some note that connects the use of "lockdep"
> with CONFIG_PROVE_LOCKING below (as that is what enables lockdep). The last
> sentence above makes it sound like lockdep can uncover latency issues, but
> it will most likely cause latency issues. Perhaps a bit more explanation
> should be used here.
>

will do.

> > +
> > +With that in mind, any false real-time kernel configuration could cause a
>
>   s/false/incorrect/ ?
>

Yup.

>
> Nice job!
>

Thanks!  I'll send a v2 on Monday.

All the best,
Ahmed