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

[Waiman Long <longman@redhat.com>]

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@kernel.org>
>>> ---
>>> 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