Re: [PATCH] doc: Add CPU Isolation documentation

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-08-09 11:42:47 [+0200], Frederic Weisbecker wrote:
> --- /dev/null
> +++ b/Documentation/admin-guide/cpu-isolation.rst
> @@ -0,0 +1,338 @@
You could start with

.. SPDX-License-Identifier: GPL-2.0

at the top.

> +=============
> +CPU Isolation
> +=============
…
> +Interface
> +~~~~~~~~~
> +
> +- :ref:`Documentation/admin-guide/cgroup-v2.rst <Cpuset v2 "isolated"
> +  partitions>`

I've been told by Jonathan once to just use the .rst file without
anything around it and the HTML render will make the link on its own.

…

> +Tradeoffs
> +~~~~~~~~~
> +
> +In terms of cost, this is the most invasive isolation feature. It is
> +assumed to be used when the workload spends most of its time in
> +userspace and doesn't rely on the kernel except for preparatory
> +work because:
> +
> +- RCU is slower due to the locked, offloaded and threaded callbacks
> +  processing (the same that would be obtained with "rcu_nocb=" boot
> +  parameter).

You mean the callback invocation is delayed? It shouldn't affect grace
period handling and so on.

…

> +Checklist
> +=========
> +
> +You have set up each of the above isolation features but you still
> +observe jitters that trash your workload? Make sure to check a few
> +elements before proceeding.
> +
> +Some of these checklist items are similar to those of real time
> +workloads:
> +
> +- Use mlock() to prevent your pages from being swapped away. Page
> +  faults are usually not compatible with jitter sensitive workloads.
> +
> +- Avoid SMT to prevent your hardware thread from being "preempted"
> +  by another one.
> +
> +- CPU frequency changes may induce subtle sorts of jitter in a
> +  workload. Cpufreq should be used and tuned with caution.
> +
> +- Deep C-states may result in latency issues upon wake-up. If this
> +  happens to be a problem, C-states can be limited via kernel boot
> +  parameters such as processor.max_cstate or intel_idle.max_cstate.
> +

I intended to make a similar list similar to this for the real time part
but it somehow faded away. There is now the idea to identify kernel
options which are not so optimal which include CPU frequency for
instance. The requirements here are should be the same.

Sebastian