linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Frederic Weisbecker <frederic@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>,
	Gabriele Monaco <gmonaco@redhat.com>,
	Ingo Molnar <mingo@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Marco Crivellari <marco.crivellari@suse.com>,
	Michal Hocko <mhocko@kernel.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Phil Auld <pauld@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Waiman Long <longman@redhat.com>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH] doc: Add CPU Isolation documentation
Date: Sat, 9 Aug 2025 18:06:54 +0700	[thread overview]
Message-ID: <aJcrzjAz6VafUsqz@archie.me> (raw)
In-Reply-To: <20250809094247.8384-1-frederic@kernel.org>

On Sat, Aug 09, 2025 at 11:42:47AM +0200, Frederic Weisbecker wrote:
> +- :ref:`Documentation/admin-guide/cgroup-v2.rst <Cpuset v2 "isolated"
> +  partitions>`
> +  are recommended because they are tunable at runtime.

Anchor link target and name are mistakenly swapped so I have to correct them
back to their appropriate places:

---- >8 ----
diff --git a/Documentation/admin-guide/cpu-isolation.rst b/Documentation/admin-guide/cpu-isolation.rst
index 250027acf7b26f..aef0b53b0ad5e6 100644
--- a/Documentation/admin-guide/cpu-isolation.rst
+++ b/Documentation/admin-guide/cpu-isolation.rst
@@ -107,9 +107,8 @@ are extracted from the global load balancing.
 Interface
 ~~~~~~~~~
 
-- :ref:`Documentation/admin-guide/cgroup-v2.rst <Cpuset v2 "isolated"
-  partitions>`
-  are recommended because they are tunable at runtime.
+- :doc:`cgroup cpuset isolated partitions <cgroup-v2>` are recommended because
+  they are tunable at runtime.
 
 - The 'isolcpus=' kernel boot parameter with the 'domain' flag is a
   less flexible alternative that doesn't allow for runtime
@@ -124,7 +123,8 @@ target CPUs.
 Interface
 ~~~~~~~~~
 
-- /proc/irq/*/smp_affinity as explained :ref:`Documentation/core-api/irq/irq-affinity.rst <here>` in detail.
+- /proc/irq/\*/smp_affinity as explained in
+  Documentation/core-api/irq/irq-affinity.rst.
 
 - The "irqaffinity=" kernel boot parameter for a default setting.
 
@@ -330,9 +330,8 @@ retained when that happens.
 
 Some tools may also be useful for higher level analysis:
 
-- :ref:`Documentation/tools/rtla/rtla-osnoise.rst <rtla-osnoise>` runs a kernel
-  tracer that analyzes and output a
-  summary of the noises.
+- :doc:`rtla-osnoise </tools/rtla/rtla-osnoise>` runs a kernel tracer that
+  analyzes and output a summary of the noises.
 
 - dynticks-testing does something similar but in userspace. It is available
   at git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git

> +The full command line is then:
> +
> +  nohz_full=7 irqaffinity=0-6 isolcpus=managed_irq,7 nosmt
> +
> +CPUSET configuration (cgroup v2)
> +--------------------------------
> +
> +Assuming cgroup v2 is mounted to /sys/fs/cgroup, the following script
> +isolates CPU 7 from scheduler domains.
> +
> +  cd /sys/fs/cgroup
> +  # Activate the cpuset subsystem
> +  echo +cpuset > cgroup.subtree_control
> +  # Create partition to be isolated
> +  mkdir test
> +  cd test
> +  echo +cpuset > cgroup.subtree_control
> +  # Isolate CPU 7
> +  echo 7 > cpuset.cpus
> +  echo "isolated" > cpuset.cpus.partition
> +
> +The userspace workload
> +----------------------
> +
> +Fake a pure userspace workload, the below program runs a dummy
> +userspace loop on the isolated CPU 7.
> +
> +  #include <stdio.h>
> +  #include <fcntl.h>
> +  #include <unistd.h>
> +  #include <errno.h>
> +  int main(void)
> +  {
> +  	// Move the current task to the isolated cpuset (bind to CPU 7)
> +  	int fd = open("/sys/fs/cgroup/test/cgroup.procs", O_WRONLY);
> +  	if (fd < 0) {
> +  		perror("Can't open cpuset file...\n");
> +  		return 0;
> +  	}
> +
> +  	write(fd, "0\n", 2);
> +  	close(fd);
> +
> +  	// Run an endless dummy loop until the launcher kills us
> +  	while (1)
> +  	;
> +
> +  	return 0;
> +  }
> +
> +Build it and save for later step:
> +
> +  # gcc user_loop.c -o user_loop
> +
> +The launcher
> +------------
> +
> +The below launcher runs the above program for 10 seconds and traces
> +the noise resulting from preempting tasks and IRQs.
> +
> +  TRACING=/sys/kernel/tracing/
> +  # Make sure tracing is off for now
> +  echo 0 > $TRACING/tracing_on
> +  # Flush previous traces
> +  echo > $TRACING/trace
> +  # Record disturbance from other tasks
> +  echo 1 > $TRACING/events/sched/sched_switch/enable
> +  # Record disturbance from interrupts
> +  echo 1 > $TRACING/events/irq_vectors/enable
> +  # Now we can start tracing
> +  echo 1 > $TRACING/tracing_on
> +  # Run the dummy user_loop for 10 seconds on CPU 7
> +  ./user_loop &
> +  USER_LOOP_PID=$!
> +  sleep 10
> +  kill $USER_LOOP_PID
> +  # Disable tracing and save traces from CPU 7 in a file
> +  echo 0 > $TRACING/tracing_on
> +  cat $TRACING/per_cpu/cpu7/trace > trace.7
> +
> +If no specific problem arose, the output of trace.7 should look like
> +the following:
> +
> +  <idle>-0 [007] d..2. 1980.976624: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=user_loop next_pid=1553 next_prio=120
> +  user_loop-1553 [007] d.h.. 1990.946593: reschedule_entry: vector=253
> +  user_loop-1553 [007] d.h.. 1990.946593: reschedule_exit: vector=253

Wrap these snippets above in literal code blocks.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

  reply	other threads:[~2025-08-09 11:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-09  9:42 [PATCH] doc: Add CPU Isolation documentation Frederic Weisbecker
2025-08-09 11:06 ` Bagas Sanjaya [this message]
2025-09-02 12:50   ` Frederic Weisbecker
2025-08-11 16:35 ` Valentin Schneider
2025-09-05 13:17   ` Frederic Weisbecker
2025-08-11 20:38 ` Waiman Long

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aJcrzjAz6VafUsqz@archie.me \
    --to=bagasdotme@gmail.com \
    --cc=anna-maria@linutronix.de \
    --cc=corbet@lwn.net \
    --cc=frederic@kernel.org \
    --cc=gmonaco@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=marco.crivellari@suse.com \
    --cc=mhocko@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pauld@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).