All of lore.kernel.org
 help / color / mirror / Atom feed
From: Uladzislau Rezki <urezki@gmail.com>
To: Andrea Righi <andrea.righi@canonical.com>
Cc: Andrea Righi <andrea.righi@canonical.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Joel Fernandes <joelaf@google.com>,
	rcu@vger.kernel.org,
	"Cc: Frederic Weisbecker" <fweisbec@gmail.com>
Subject: Re: Observation on NOHZ_FULL
Date: Thu, 8 Feb 2024 15:51:06 +0100	[thread overview]
Message-ID: <ZcTqWiCJXg4H1wxp@pc636> (raw)
In-Reply-To: <ZcTO5lKeZoJZH1Mp@pc636>

On Thu, Feb 08, 2024 at 01:53:58PM +0100, Uladzislau Rezki wrote:
> On Thu, Feb 08, 2024 at 07:55:37AM +0100, Andrea Righi wrote:
> > On Thu, Feb 08, 2024 at 12:54:58AM -0500, Joel Fernandes wrote:
> > ...
> > > >> Slightly related, but one of the things we are wondering also is how
> > > >> much of the overhead for your nohz-full and lazy-RCU test (on top of
> > > >> baseline - that is just CONFIG_HZ=1000 without nohz-full or nocbs) is
> > > >> because of just using NOCB. Uladsizlau mentioned he might run a test
> > > >> for comparing along those lines as well.
> > > > 
> > > > Just to clarify, "lazy rcu on" results are just with rcu_nocb=all and
> > > > lazy RCUs enabled (and HZ=1000), so without nohz_full.
> > > > 
> > > > If I enable only nohz_full=all (without rcu_nocb) I see something like
> > > > this:
> > > 
> > > Ok. I did want to mention nohz_full implies rcu_nocb on the same CPUs as well.
> > > 
> > > Its also mentioned in the boot param docs on the last line of the description:
> > > 
> > >         nohz_full=      [KNL,BOOT,SMP,ISOL]
> > >                         The argument is a cpu list, as described above.
> > >                         In kernels built with CONFIG_NO_HZ_FULL=y, set
> > >                         the specified list of CPUs whose tick will be stopped
> > >                         whenever possible. The boot CPU will be forced outside
> > >                         the range to maintain the timekeeping.  Any CPUs
> > >                         in this list will have their RCU callbacks offloaded,
> > >                         just as if they had also been called out in the
> > >                         rcu_nocbs= boot parameter.
> > 
> > Ah I didn't realize that, it definitely makes sense, thanks for
> > clarifying it.
> > 
> > Then basically in the results that I posted the difference is
> > "nohz_full=all+rcu_nocb=all" vs "rcu_nocb=all+lazy_RCU=on".
> > 
> So, you say that a hrtimer_interrupt() handler takes more time in case
> of lazy + nocb + rcu_nocb=all and for nohz_full + rcu_nocb=all it faster?
> Could you please clarify this? I will try to measure from my side!
> 
> I have done some basic research about hrtimer_interrupt() latency on my
> HW with latest Linux kernel. I have compared below cases:
> 
> case a: 1000HZ + lazy + nocb_all_cpus
> case b: 1000HZ + nocb_all_cpus
> 
> I used "ftrace" to measure time(in microseconds). Steps:
> 
> echo 0 > tracing_on
> echo function_graph > current_tracer
> echo funcgraph-proc > trace_options
> echo funcgraph-abstime > trace_options
> echo hrtimer_interrupt > set_ftrace_filter
> 
> fio --rw=write --bs=1M --size=1G --numjobs=8 --name=worker --time_based --runtime=50&
> 
> echo 1 > tracing_on; sleep 10; echo 0 > tracing_on
> 
> data is based on 10 seconds collection:
> 
> <case a>
>      6  2102 ############################################################
>      8  2079 ############################################################
>     10  1464 ##########################################
>      7   897 ##########################
>      9   625 ##################
>     12   490 ##############
>     13   479 ##############
>     11   289 #########
>      5   249 ########
>     14   124 ####
>     15    72 ###
>     16    41 ##
>     17    24 #
>      4    22 #
>     18    12 #
>     22     2 #
>     19     1 #
> <case a>
> 
> <case b>
>      9  1658 ############################################################
>     13  1308 ################################################
>     12  1224 #############################################
>     10   972 ####################################
>      8   703 ##########################
>     14   595 ######################
>     15   571 #####################
>     11   525 ###################
>     17   350 #############
>     16   235 #########
>      7   214 ########
>      4    73 ###
>      5    68 ###
>      6    54 ##
>     20     9 #
>     18     9 #
>     19     6 #
>     33     1 #
>      3     1 #
>     28     1 #
>     27     1 #
>     25     1 #
>     22     1 #
>     21     1 #
> <case b>
> 
> I do not see the difference, there is a nose of 1/2/3 microseconds diff.
> 
Let me further have a look at what we use for lazy in terms on hrtimer though.

--
Uladzislau Rezki

  reply	other threads:[~2024-02-08 14:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 17:47 Observation on NOHZ_FULL Joel Fernandes
2024-01-29 20:41 ` Paul E. McKenney
2024-01-29 22:16   ` Joel Fernandes
2024-01-30  6:58     ` Andrea Righi
2024-01-30 10:17       ` Paul E. McKenney
2024-01-30 11:06         ` Uladzislau Rezki
2024-01-30 11:27           ` Andrea Righi
2024-01-30 11:41             ` Uladzislau Rezki
2024-01-30 13:39             ` Paul E. McKenney
2024-02-06 17:51               ` Andrea Righi
2024-02-06 18:44                 ` Paul E. McKenney
2024-02-07 13:04                   ` Uladzislau Rezki
2024-02-07 15:12                     ` Andrea Righi
2024-02-07 15:49                       ` Joel Fernandes
2024-02-15  7:51                   ` Andrea Righi
2024-02-15 13:15                     ` Uladzislau Rezki
2024-02-15 14:02                       ` Joel Fernandes
2024-02-07 15:48                 ` Joel Fernandes
2024-02-07 16:31                   ` Andrea Righi
2024-02-07 16:52                     ` Joel Fernandes
2024-02-07 17:05                       ` Andrea Righi
2024-02-08  5:54                         ` Joel Fernandes
2024-02-08  6:55                           ` Andrea Righi
2024-02-08 12:53                             ` Uladzislau Rezki
2024-02-08 14:51                               ` Uladzislau Rezki [this message]
2024-02-12  0:22                                 ` Joel Fernandes
2024-02-12  9:05                                   ` Uladzislau Rezki
2024-02-12  9:44                                   ` Uladzislau Rezki
2024-01-29 20:48 ` Uladzislau Rezki
2024-01-29 22:20   ` Joel Fernandes
2024-01-29 22:43     ` Frederic Weisbecker
2024-01-29 22:53       ` Joel Fernandes
2024-01-29 23:11         ` Frederic Weisbecker
2024-01-29 23:36           ` Joel Fernandes
2024-01-30  0:40       ` Paul E. McKenney

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=ZcTqWiCJXg4H1wxp@pc636 \
    --to=urezki@gmail.com \
    --cc=andrea.righi@canonical.com \
    --cc=fweisbec@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=joelaf@google.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.