Re: [PATCH] doc: Add CPU Isolation documentation

[Frederic Weisbecker <frederic@kernel.org>]

Le Fri, Mar 20, 2026 at 04:10:36PM +0100, Sebastian Andrzej Siewior a écrit :
> 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.

Ok.

> 
> > +=============
> > +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.
> 
> …

Hmm, how would that look like? Just this?

+- Documentation/admin-guide/cgroup-v2.rst

> 
> > +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.
> 
> …

Right.

> 
> > +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.

We should probably have this to a seperate file that both isolation and rt could
link to?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs