From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joel Fernandes <joelaf@google.com>
Cc: linux-kernel@vger.kernel.org,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zilstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Boqun Feng <boqun.feng@gmail.com>,
byungchul.park@lge.com, kernel-team@android.com,
Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>
Subject: Re: [PATCH v2] rcu: Speed up calling of RCU tasks callbacks
Date: Sun, 20 May 2018 20:02:25 -0700 [thread overview]
Message-ID: <20180521030225.GA3803@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180521004324.68371-1-joel@joelfernandes.org>
On Sun, May 20, 2018 at 05:43:24PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
>
> RCU tasks callbacks can take atleast 1 second before the callbacks are
> executed. This happens even if the hold-out tasks enter their quiescent states
> quickly. I noticed this when I was testing trampoline callback execution.
>
> To test the trampoline freeing, I wrote a simple script:
> cd /sys/kernel/debug/tracing/
> echo '__schedule_bug:traceon' > set_ftrace_filter;
> echo '!__schedule_bug:traceon' > set_ftrace_filter;
>
> In the background I had simple bash while loop:
> while [ 1 ]; do x=1; done &
>
> Total time of completion of above commands in seconds:
>
> With this patch:
> real 0m0.179s
> user 0m0.000s
> sys 0m0.054s
>
> Without this patch:
> real 0m1.098s
> user 0m0.000s
> sys 0m0.053s
>
> That's a great than 6X speed up in performance. In order to accomplish
> this, I am waiting for HZ/10 time before entering the hold-out checking
> loop. The loop still preserves its checking of held tasks every 1 second
> as before, incase this first test doesn't succeed.
>
> Cc: Steven Rostedt <rostedt@goodmis.org>
Seems straightforward enough. The commit log needs a bit of cleanup
("atleast", "great than", ...).
Steve, thoughts? Any reason why this would be a problem?
Thanx, Paul
> Cc: Peter Zilstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
> Cc: byungchul.park@lge.com
> Cc: kernel-team@android.com
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> Changes since v1->v2:
> - Changed total wait time to HZ/10 instead of 2 jiffies
> - Updated the commands to reproduce issue
>
> kernel/rcu/update.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 5783bdf86e5a..a28698e44b08 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -743,6 +743,12 @@ static int __noreturn rcu_tasks_kthread(void *arg)
> */
> synchronize_srcu(&tasks_rcu_exit_srcu);
>
> + /*
> + * Wait a little bit incase held tasks are released
> + * during their next timer ticks.
> + */
> + schedule_timeout_interruptible(HZ/10);
> +
> /*
> * Each pass through the following loop scans the list
> * of holdout tasks, removing any that are no longer
> @@ -755,7 +761,6 @@ static int __noreturn rcu_tasks_kthread(void *arg)
> int rtst;
> struct task_struct *t1;
>
> - schedule_timeout_interruptible(HZ);
> rtst = READ_ONCE(rcu_task_stall_timeout);
> needreport = rtst > 0 &&
> time_after(jiffies, lastreport + rtst);
> @@ -768,6 +773,11 @@ static int __noreturn rcu_tasks_kthread(void *arg)
> check_holdout_task(t, needreport, &firstreport);
> cond_resched();
> }
> +
> + if (list_empty(&rcu_tasks_holdouts))
> + break;
> +
> + schedule_timeout_interruptible(HZ);
> }
>
> /*
> --
> 2.17.0.441.gb46fe60e1d-goog
>
prev parent reply other threads:[~2018-05-21 3:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-21 0:43 [PATCH v2] rcu: Speed up calling of RCU tasks callbacks Joel Fernandes
2018-05-21 3:02 ` Paul E. McKenney [this message]
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=20180521030225.GA3803@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=byungchul.park@lge.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=joelaf@google.com \
--cc=josh@joshtriplett.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.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.