Re: [PATCH v2] doc: Add CPU Isolation documentation

[Waiman Long]

On 4/1/26 11:47 AM, Frederic Weisbecker wrote:
> Le Thu, Mar 26, 2026 at 03:17:48PM -0400, Waiman Long a écrit :
> > On 3/26/26 10:00 AM, Frederic Weisbecker wrote:
> > > nohz_full was introduced in v3.10 in 2013, which means this
> > > documentation is overdue for 13 years.
> > >
> > > Fortunately Paul wrote a part of the needed documentation a while ago,
> > > especially concerning nohz_full in Documentation/timers/no_hz.rst and
> > > also about per-CPU kthreads in
> > > Documentation/admin-guide/kernel-per-CPU-kthreads.rst
> > >
> > > Introduce a new page that gives an overview of CPU isolation in general.
> > >
> > > Signed-off-by: Frederic Weisbecker <frederic@xxxxxxxxxx>
> > > ---
> > > v2:
> > >      - Fix links and code blocks (Bagas and Sebastian)
> > >      - Isolation is not only about userspace, rephrase accordingly (Valentin)
> > >      - Paste BIOS issues suggestion from Valentin
> > >      - Include the whole rtla suite (Valentin)
> > >      - Rephrase a few details (Waiman)
> > >      - Talk about RCU induced overhead rather than slower RCU (Sebastian)
> > >
> > >    Documentation/admin-guide/cpu-isolation.rst | 357 ++++++++++++++++++++
> > >    Documentation/admin-guide/index.rst         |   1 +
> > >    2 files changed, 358 insertions(+)
> > >    create mode 100644 Documentation/admin-guide/cpu-isolation.rst
> > >
> > > diff --git a/Documentation/admin-guide/cpu-isolation.rst b/Documentation/admin-guide/cpu-isolation.rst
> > > new file mode 100644
> > > index 000000000000..886dec79b056
> > > --- /dev/null
> > > +++ b/Documentation/admin-guide/cpu-isolation.rst
> > > @@ -0,0 +1,357 @@
> > > +.. SPDX-License-Identifier: GPL-2.0
> > > +
> > > +=============
> > > +CPU Isolation
> > > +=============
> > > +
> > > +Introduction
> > > +============
> > > +
> > > +"CPU Isolation" means leaving a CPU exclusive to a given workload
> > > +without any undesired code interference from the kernel.
> > > +
> > > +Those interferences, commonly pointed out as "noise", can be triggered
> > > +by asynchronous events (interrupts, timers, scheduler preemption by
> > > +workqueues and kthreads, ...) or synchronous events (syscalls and page
> > > +faults).
> > > +
> > > +Such noise usually goes unnoticed. After all synchronous events are a
> > > +component of the requested kernel service. And asynchronous events are
> > > +either sufficiently well distributed by the scheduler when executed
> > > +as tasks or reasonably fast when executed as interrupt. The timer
> > > +interrupt can even execute 1024 times per seconds without a significant
> > > +and measurable impact most of the time.
> > > +
> > > +However some rare and extreme workloads can be quite sensitive to
> > > +those kinds of noise. This is the case, for example, with high
> > > +bandwidth network processing that can't afford losing a single packet
> > > +or very low latency network processing. Typically those usecases
> > > +involve DPDK, bypassing the kernel networking stack and performing
> > > +direct access to the networking device from userscace.
> > As also pointed by by Sashiko, there is a typo "userscace" -> "userspace".
> > There are also typos reported in
> >
> > https://sashiko.dev/#/patchset/20260326140055.41555-1-frederic%40kernel.org
> Thanks!
>
> What do you think about these lines of Sashiko's review:
>
> """
> Does this script violate the cgroup v2 "no internal process" constraint?
> By enabling the cpuset controller on the test directory's
> cgroup.subtree_control file, the cgroup cannot also contain processes.
> """
>
> That is confusing me...

I would say that the "no internal process" is a suggestion for the 
cgroup setup. The real world is actually more complicated. So I will 
just ignore that.

Cheers,
Longman