All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	linux-kernel@vger.kernel.org, Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	linux-doc@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [PATCH v3] rcu: Add a minimum time for marking boot as completed
Date: Thu, 9 Mar 2023 22:10:56 +0000	[thread overview]
Message-ID: <20230309221056.GB148448@google.com> (raw)
In-Reply-To: <ZAnXxr9OyFT63xSx@pc636>

On Thu, Mar 09, 2023 at 01:57:42PM +0100, Uladzislau Rezki wrote:
[..]
> > > > > > See this commit:
> > > > > > 
> > > > > > 3705b88db0d7cc ("rcu: Add a module parameter to force use of
> > > > > > expedited RCU primitives")
> > > > > > 
> > > > > > Antti provided this commit precisely in order to allow Android
> > > > > > devices to expedite the boot process and to shut off the
> > > > > > expediting at a time of Android userspace's choosing.  So Android
> > > > > > has been making this work for about ten years, which strikes me
> > > > > > as an adequate proof of concept.  ;-)
> > > > > 
> > > > > Thanks for the pointer. That's true. Looking at Android sources, I
> > > > > find that Android Mediatek devices at least are setting
> > > > > rcu_expedited to 1 at late stage of their userspace boot (which is
> > > > > weird, it should be set to 1 as early as possible), and
> > > > > interestingly I cannot find them resetting it back to 0!.  Maybe
> > > > > they set rcu_normal to 1? But I cannot find that either. Vlad? :P
> > > > 
> > > > Interesting.  Though this is consistent with Antti's commit log,
> > > > where he talks about expediting grace periods but not unexpediting
> > > > them.
> > > > 
> > > Do you think we need to unexpedite it? :))))
> > 
> > Android runs on smallish systems, so quite possibly not!
> > 
> We keep it enabled and never unexpedite it. The reason is a performance.  I
> have done some app-launch time analysis with enabling and disabling of it.
> 
> An expedited case is much better when it comes to app launch time. It
> requires ~25% less time to run an app comparing with unexpedited variant.
> So we have a big gain here.

Wow, that's huge. I wonder if you can dig deeper and find out why that is so
as the callbacks may need to be synchronize_rcu_expedited() then, as it could
be slowing down other usecases! I find it hard to believe, real-time
workloads will run better without those callbacks being always-expedited if
it actually gives back 25% in performance!

thanks,

 - Joel


  reply	other threads:[~2023-03-09 22:11 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 21:38 [PATCH v3] rcu: Add a minimum time for marking boot as completed Joel Fernandes (Google)
2023-03-04  1:02 ` Paul E. McKenney
2023-03-04  4:51   ` Joel Fernandes
2023-03-11 20:44     ` Paul E. McKenney
2023-03-11 22:23       ` Joel Fernandes
2023-03-11 22:57         ` Paul E. McKenney
2023-03-06  8:24   ` Zhuo, Qiuxu
2023-03-06 14:49     ` Paul E. McKenney
2023-03-07  7:49       ` Zhuo, Qiuxu
2023-03-07 15:22         ` Paul E. McKenney
2023-03-09 15:17           ` Zhuo, Qiuxu
2023-03-09 21:53             ` Paul E. McKenney
2023-03-10  0:11               ` Akira Yokosawa
2023-03-10  1:47                 ` Paul E. McKenney
2023-03-10  2:35                 ` Zhuo, Qiuxu
2023-03-05 11:39 ` Uladzislau Rezki
2023-03-05 15:03   ` Joel Fernandes
2023-03-06  8:37     ` Zhuo, Qiuxu
2023-03-05 20:34   ` Paul E. McKenney
2023-03-07 13:01 ` Frederic Weisbecker
2023-03-07 13:40   ` Uladzislau Rezki
2023-03-07 13:48     ` Joel Fernandes
2023-03-07 17:33       ` Paul E. McKenney
2023-03-07 18:54         ` Joel Fernandes
2023-03-07 19:27           ` Paul E. McKenney
2023-03-08  9:41             ` Uladzislau Rezki
2023-03-08 14:45               ` Paul E. McKenney
2023-03-09 12:57                 ` Uladzislau Rezki
2023-03-09 22:10                   ` Joel Fernandes [this message]
2023-03-10  8:55                     ` Uladzislau Rezki
2023-03-11  6:24                       ` Paul E. McKenney
2023-03-11 17:19                         ` Joel Fernandes
2023-03-13  9:51                         ` Uladzislau Rezki
2023-03-13 12:27                           ` Uladzislau Rezki
2023-03-13 13:48                             ` Zhuo, Qiuxu
2023-03-13 15:28                               ` Uladzislau Rezki
2023-03-13 13:58                           ` Joel Fernandes
2023-03-13 15:32                             ` Uladzislau Rezki
2023-03-13 15:49                               ` Joel Fernandes
2023-03-13 18:12                                 ` Uladzislau Rezki
2023-03-13 18:56                                   ` Paul E. McKenney
2023-03-14 11:16                                     ` Uladzislau Rezki
2023-03-14 13:49                                       ` Paul E. McKenney
2023-03-14 22:44                               ` Joel Fernandes
2023-03-15 17:12                                 ` Uladzislau Rezki
2023-03-15 12:21                       ` Joel Fernandes
2023-03-15 16:12                         ` Paul E. McKenney
2023-03-08 10:14       ` Uladzislau Rezki
2023-03-15 12:18         ` Joel Fernandes
2023-03-07 13:41   ` Joel Fernandes
2023-03-07 17:19     ` Frederic Weisbecker
2023-03-07 18:19       ` Joel Fernandes
2023-03-08 13:52       ` Joel Fernandes
2023-03-08 15:01         ` Frederic Weisbecker
2023-03-08 15:09           ` Joel Fernandes

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=20230309221056.GB148448@google.com \
    --to=joel@joelfernandes.org \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=qiuxu.zhuo@intel.com \
    --cc=rcu@vger.kernel.org \
    --cc=urezki@gmail.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 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.