All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Aubrey" <aubrey.li@linux.intel.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: paulmck@kernel.org, linux-kernel@vger.kernel.org,
	vpillai <vpillai@digitalocean.com>,
	Aaron Lu <aaron.lwe@gmail.com>,
	Aubrey Li <aubrey.intel@gmail.com>,
	peterz@infradead.org, Ben Segall <bsegall@google.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH] sched: Use RCU-sched in core-scheduling balancing logic
Date: Tue, 24 Mar 2020 11:01:27 +0800	[thread overview]
Message-ID: <6d933ce2-75e3-6469-4bb0-08ce9df29139@linux.intel.com> (raw)
In-Reply-To: <20200323152126.GA141027@google.com>

On 2020/3/23 23:21, Joel Fernandes wrote:
> On Mon, Mar 23, 2020 at 02:58:18PM +0800, Li, Aubrey wrote:
>> On 2020/3/14 8:30, Paul E. McKenney wrote:
>>> On Fri, Mar 13, 2020 at 07:29:18PM -0400, Joel Fernandes (Google) wrote:
>>>> rcu_read_unlock() can incur an infrequent deadlock in
>>>> sched_core_balance(). Fix this by using the RCU-sched flavor instead.
>>>>
>>>> This fixes the following spinlock recursion observed when testing the
>>>> core scheduling patches on PREEMPT=y kernel on ChromeOS:
>>>>
>>>> [   14.998590] watchdog: BUG: soft lockup - CPU#0 stuck for 11s! [kworker/0:10:965]
>>>>
>>>
>>> The original could indeed deadlock, and this would avoid that deadlock.
>>> (The commit to solve this deadlock is sadly not yet in mainline.)
>>>
>>> Acked-by: Paul E. McKenney <paulmck@kernel.org>
>>
>> I saw this in dmesg with this patch, is it expected?
>>
>> [  117.000905] =============================
>> [  117.000907] WARNING: suspicious RCU usage
>> [  117.000911] 5.5.7+ #160 Not tainted
>> [  117.000913] -----------------------------
>> [  117.000916] kernel/sched/core.c:4747 suspicious rcu_dereference_check() usage!
>> [  117.000918] 
>>                other info that might help us debug this:
> 
> Sigh, this is because for_each_domain() expects rcu_read_lock(). From an RCU
> PoV, the code is correct (warning doesn't cause any issue).
> 
> To silence warning, we could replace the rcu_read_lock_sched() in my patch with:
> preempt_disable();
> rcu_read_lock();
> 
> and replace the unlock with:
> 
> rcu_read_unlock();
> preempt_enable();
> 
> That should both take care of both the warning and the scheduler-related
> deadlock. Thoughts?
> 

How about this?

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a01df3e..7ff694e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4743,7 +4743,6 @@ static void sched_core_balance(struct rq *rq)
 	int cpu = cpu_of(rq);
 
 	rcu_read_lock();
-	raw_spin_unlock_irq(rq_lockp(rq));
 	for_each_domain(cpu, sd) {
 		if (!(sd->flags & SD_LOAD_BALANCE))
 			break;
@@ -4754,7 +4753,6 @@ static void sched_core_balance(struct rq *rq)
 		if (steal_cookie_task(cpu, sd))
 			break;
 	}
-	raw_spin_lock_irq(rq_lockp(rq));
 	rcu_read_unlock();
 }

Thanks,
-Aubrey

  reply	other threads:[~2020-03-24  3:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13 23:29 [PATCH] sched: Use RCU-sched in core-scheduling balancing logic Joel Fernandes (Google)
2020-03-14  0:30 ` Paul E. McKenney
2020-03-23  6:58   ` Li, Aubrey
2020-03-23 15:21     ` Joel Fernandes
2020-03-24  3:01       ` Li, Aubrey [this message]
2020-03-24 13:30         ` Paul E. McKenney
2020-03-24 15:12           ` Paul E. McKenney
2020-03-24 18:49         ` Joel Fernandes
2020-03-25  0:40           ` Li, Aubrey

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=6d933ce2-75e3-6469-4bb0-08ce9df29139@linux.intel.com \
    --to=aubrey.li@linux.intel.com \
    --cc=aaron.lwe@gmail.com \
    --cc=aubrey.intel@gmail.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vpillai@digitalocean.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.