From: Josh Don <joshdon@google.com>
To: Aubrey Li <aubrey.intel@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Joel Fernandes <joel@joelfernandes.org>,
"Hyser,Chris" <chris.hyser@oracle.com>,
Ingo Molnar <mingo@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Valentin Schneider <valentin.schneider@arm.com>,
Mel Gorman <mgorman@suse.de>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Don Hiatt <dhiatt@digitalocean.com>
Subject: Re: [PATCH 04/19] sched: Prepare for Core-wide rq->lock
Date: Fri, 30 Apr 2021 01:48:32 -0700 [thread overview]
Message-ID: <CABk29NtLR5q_i=CGyCqtjR5ruJ1dtWN=_JB8wiRhxgevdCiPPQ@mail.gmail.com> (raw)
In-Reply-To: <CAERHkrvTkN3zJFr0RpO02wF1KdhgqWZL8VpFohc4i7qPzvr8Cg@mail.gmail.com>
On Fri, Apr 30, 2021 at 1:20 AM Aubrey Li <aubrey.intel@gmail.com> wrote:
>
> On Fri, Apr 30, 2021 at 4:40 AM Josh Don <joshdon@google.com> wrote:
> >
> > On Thu, Apr 29, 2021 at 1:03 AM Aubrey Li <aubrey.intel@gmail.com> wrote:
> > >
> > > On Thu, Apr 22, 2021 at 8:39 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > > ----snip----
> > > > @@ -199,6 +224,25 @@ void raw_spin_rq_unlock(struct rq *rq)
> > > > raw_spin_unlock(rq_lockp(rq));
> > > > }
> > > >
> > > > +#ifdef CONFIG_SMP
> > > > +/*
> > > > + * double_rq_lock - safely lock two runqueues
> > > > + */
> > > > +void double_rq_lock(struct rq *rq1, struct rq *rq2)
> > > > +{
> > > > + lockdep_assert_irqs_disabled();
> > > > +
> > > > + if (rq1->cpu > rq2->cpu)
> > >
> > > It's still a bit hard for me to digest this function, I guess using (rq->cpu)
> > > can't guarantee the sequence of locking when coresched is enabled.
> > >
> > > - cpu1 and cpu7 shares lockA
> > > - cpu2 and cpu8 shares lockB
> > >
> > > double_rq_lock(1,8) leads to lock(A) and lock(B)
> > > double_rq_lock(7,2) leads to lock(B) and lock(A)
> > >
> > > change to below to avoid ABBA?
> > > + if (__rq_lockp(rq1) > __rq_lockp(rq2))
> > >
> > > Please correct me if I was wrong.
> >
> > Great catch Aubrey. This is possibly what is causing the lockups that
> > Don is seeing.
> >
> > The proposed usage of __rq_lockp() is prone to race with sched core
> > being enabled/disabled.It also won't order properly if we do
> > double_rq_lock(smt0, smt1) vs double_rq_lock(smt1, smt0), since these
> > would have equivalent __rq_lockp()
>
> If __rq_lockp(smt0) == __rq_lockp(smt1), rq0 and rq1 won't swap,
> Later only one rq is locked and just returns. I'm not sure how does it not
> order properly?
If there is a concurrent switch from sched_core enable <-> disable,
the value of __rq_lockp() will race.
In the version you posted directly above, where we swap rq1 and rq2 if
__rq_lockp(rq1) > __rqlockp(rq2) rather than comparing the cpu, the
following can happen:
cpu 1 and cpu 7 share a core lock when coresched is enabled
- schedcore enabled
- double_lock(7, 1)
- __rq_lockp compares equal for 7 and 1; no swap is done
- schedcore disabled; now __rq_lockp returns the per-rq lock
- lock(__rq_lockp(7)) => lock(7)
- lock(__rq_lockp(1)) => lock(1)
Then we can also have
- schedcore disabled
- double_lock(1, 7)
- __rq_lock(1) < rq_lock(7), so no swap
- lock(__rqlockp(1)) => lock(1)
- lock(__rq_lockp(7)) => lock(7)
So we have in the first 7->1 and in the second 1->7
>
> .> I'd propose an alternative but similar idea: order by core, then break ties
> > by ordering on cpu.
> >
> > +#ifdef CONFIG_SCHED_CORE
> > + if (rq1->core->cpu > rq2->core->cpu)
> > + swap(rq1, rq2);
> > + else if (rq1->core->cpu == rq2->core->cpu && rq1->cpu > rq2->cpu)
> > + swap(rq1, rq2);
>
> That is, why the "else if" branch is needed?
Ensuring that core siblings always take their locks in the same order
if coresched is disabled.
>
> > +#else
> > if (rq1->cpu > rq2->cpu)
> > swap(rq1, rq2);
> > +#endif
Best,
Josh
next prev parent reply other threads:[~2021-04-30 8:48 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 12:04 [PATCH 00/19] sched: Core Scheduling Peter Zijlstra
2021-04-22 12:05 ` [PATCH 01/19] sched/fair: Add a few assertions Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-05-13 8:56 ` Ning, Hongyu
2021-04-22 12:05 ` [PATCH 02/19] sched: Provide raw_spin_rq_*lock*() helpers Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 03/19] sched: Wrap rq::lock access Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 04/19] sched: Prepare for Core-wide rq->lock Peter Zijlstra
2021-04-24 1:22 ` Josh Don
2021-04-26 8:31 ` Peter Zijlstra
2021-04-26 22:21 ` Josh Don
2021-04-27 17:10 ` Don Hiatt
2021-04-27 23:35 ` Josh Don
2021-04-28 1:03 ` Aubrey Li
2021-04-28 6:05 ` Aubrey Li
2021-04-28 10:57 ` Aubrey Li
2021-04-28 16:41 ` Don Hiatt
2021-04-29 20:48 ` Josh Don
2021-04-29 21:09 ` Don Hiatt
2021-04-29 23:22 ` Josh Don
2021-04-30 16:18 ` Don Hiatt
2021-04-30 8:26 ` Aubrey Li
2021-04-28 16:04 ` Don Hiatt
2021-04-27 23:30 ` Josh Don
2021-04-28 9:13 ` Peter Zijlstra
2021-04-28 10:35 ` Aubrey Li
2021-04-28 11:03 ` Peter Zijlstra
2021-04-28 14:18 ` Paul E. McKenney
2021-04-29 20:11 ` Josh Don
2021-05-03 19:17 ` Peter Zijlstra
2021-04-28 7:13 ` Peter Zijlstra
2021-04-28 6:02 ` Aubrey Li
2021-04-29 8:03 ` Aubrey Li
2021-04-29 20:39 ` Josh Don
2021-04-30 8:20 ` Aubrey Li
2021-04-30 8:48 ` Josh Don [this message]
2021-04-30 14:15 ` Aubrey Li
2021-05-04 7:38 ` Peter Zijlstra
2021-05-05 16:20 ` Don Hiatt
2021-05-06 10:25 ` Peter Zijlstra
2021-05-07 9:50 ` [PATCH v2 " Peter Zijlstra
2021-05-08 8:07 ` Aubrey Li
2021-05-12 9:07 ` Peter Zijlstra
2021-04-22 12:05 ` [PATCH 05/19] sched: " Peter Zijlstra
2021-05-07 9:50 ` [PATCH v2 " Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 06/19] sched: Optimize rq_lockp() usage Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 07/19] sched: Allow sched_core_put() from atomic context Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 08/19] sched: Introduce sched_class::pick_task() Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 09/19] sched: Basic tracking of matching tasks Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 10/19] sched: Add core wide task selection and scheduling Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 11/19] sched/fair: Fix forced idle sibling starvation corner case Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Vineeth Pillai
2021-04-22 12:05 ` [PATCH 12/19] sched: Fix priority inversion of cookied task with sibling Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Joel Fernandes (Google)
2021-04-22 12:05 ` [PATCH 13/19] sched/fair: Snapshot the min_vruntime of CPUs on force idle Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Joel Fernandes (Google)
2021-04-22 12:05 ` [PATCH 14/19] sched: Trivial forced-newidle balancer Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 15/19] sched: Migration changes for core scheduling Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Aubrey Li
2021-04-22 12:05 ` [PATCH 16/19] sched: Trivial core scheduling cookie management Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 17/19] sched: Inherit task cookie on fork() Peter Zijlstra
2021-05-10 16:06 ` Joel Fernandes
2021-05-10 16:22 ` Chris Hyser
2021-05-10 20:47 ` Joel Fernandes
2021-05-10 21:38 ` Chris Hyser
2021-05-12 9:05 ` Peter Zijlstra
2021-05-12 20:20 ` Josh Don
2021-05-12 21:07 ` Don Hiatt
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 18/19] sched: prctl() core-scheduling interface Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Chris Hyser
2021-06-14 23:36 ` [PATCH 18/19] " Josh Don
2021-06-15 11:31 ` Joel Fernandes
2021-08-05 16:53 ` Eugene Syromiatnikov
2021-08-05 17:00 ` Peter Zijlstra
2021-08-17 15:15 ` Eugene Syromiatnikov
2021-08-17 15:52 ` Peter Zijlstra
2021-08-17 23:17 ` Eugene Syromiatnikov
2021-08-19 11:09 ` [PATCH] sched: Fix Core-wide rq->lock for uninitialized CPUs Peter Zijlstra
2021-08-19 15:50 ` Tao Zhou
2021-08-19 16:19 ` Eugene Syromiatnikov
2021-08-20 0:18 ` Josh Don
2021-08-20 10:02 ` Peter Zijlstra
2021-08-23 9:07 ` [tip: sched/urgent] " tip-bot2 for Peter Zijlstra
2021-04-22 12:05 ` [PATCH 19/19] kselftest: Add test for core sched prctl interface Peter Zijlstra
2021-05-12 10:28 ` [tip: sched/core] " tip-bot2 for Chris Hyser
2021-04-22 16:43 ` [PATCH 00/19] sched: Core Scheduling Don Hiatt
2021-04-22 17:29 ` Peter Zijlstra
2021-04-30 6:47 ` Ning, Hongyu
2021-05-06 10:29 ` Peter Zijlstra
2021-05-06 12:53 ` Ning, Hongyu
2021-05-07 18:02 ` Joel Fernandes
2021-05-10 16:16 ` Vincent Guittot
2021-05-11 7:00 ` Vincent Guittot
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='CABk29NtLR5q_i=CGyCqtjR5ruJ1dtWN=_JB8wiRhxgevdCiPPQ@mail.gmail.com' \
--to=joshdon@google.com \
--cc=aubrey.intel@gmail.com \
--cc=chris.hyser@oracle.com \
--cc=dhiatt@digitalocean.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).