From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754131AbeEWGij (ORCPT ); Wed, 23 May 2018 02:38:39 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:40862 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754101AbeEWGid (ORCPT ); Wed, 23 May 2018 02:38:33 -0400 X-Google-Smtp-Source: AB8JxZp9DNNmnLvyay7WJbTfVc9XxWU1/LVzlmjjihdRP5WaGsPbiMfKwYHbks0prKankNCuXbcebQ== From: Joel Fernandes X-Google-Original-From: Joel Fernandes To: linux-kernel@vger.kernel.org Cc: "Joel Fernandes (Google)" , Steven Rostedt , Peter Zilstra , Ingo Molnar , Boqun Feng , Paul McKenney , byungchul.park@lge.com, kernel-team@android.com, Josh Triplett , Lai Jiangshan , Mathieu Desnoyers Subject: [PATCH 1/4] rcu: Speed up calling of RCU tasks callbacks Date: Tue, 22 May 2018 23:38:12 -0700 Message-Id: <20180523063815.198302-2-joel@joelfernandes.org> X-Mailer: git-send-email 2.17.0.441.gb46fe60e1d-goog In-Reply-To: <20180523063815.198302-1-joel@joelfernandes.org> References: <20180523063815.198302-1-joel@joelfernandes.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Joel Fernandes (Google)" RCU tasks callbacks can take at least 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 greater 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, in case this first test doesn't succeed. Cc: Steven Rostedt Cc: Peter Zilstra Cc: Ingo Molnar Cc: Boqun Feng Cc: Paul McKenney Cc: byungchul.park@lge.com Cc: kernel-team@android.com Signed-off-by: Joel Fernandes (Google) --- 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