From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Krister Johansen <kjlx@templeofstupid.com>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.
Date: Thu, 15 Jun 2017 20:09:14 -0700 [thread overview]
Message-ID: <20170616030914.GM3721@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170616010757.kegygn4ndivdb4wh@tardis>
On Fri, Jun 16, 2017 at 09:07:57AM +0800, Boqun Feng wrote:
> On Thu, Jun 15, 2017 at 10:56:29AM -0700, Paul E. McKenney wrote:
> [...]
> > > >
> > > > FWLIW, I agree. There was a smb_mb() in RT-linux's equivalent of
> > > > swait_activate().
> > > >
> > > > https://www.spinics.net/lists/linux-rt-users/msg10340.html
> > > >
> > > > If the barrier goes in swait_active() then we don't have to require all
> > > > of the callers of swait_active and swake_up to issue the barrier
> > > > instead. Handling this in swait_active is likely to be less error
> > > > prone. Though, we could also do something like wq_has_sleeper() and use
> > > > that preferentially in swake_up and its variants.
> > > >
> > >
> > > I think it makes more sense that we delete the swait_active() in
> > > swake_up()? Because we seems to encourage users to do the quick check on
> > > wait queue on their own, so why do the check again in swake_up()?
> > > Besides, wake_up() doesn't call waitqueue_activie() outside the lock
> > > critical section either.
> > >
> > > So how about the patch below(Testing is in progress)? Peter?
> >
> > It is quite possible that a problem I am seeing is caused by this, but
> > there are reasons to believe otherwise. And in any case, the problem is
> > quite rare, taking tens or perhaps even hundreds of hours of rcutorture
> > to reproduce.
> >
> > So, would you be willing to create a dedicated swait torture test to check
> > this out? The usual approach would be to create a circle of kthreads,
> > with each waiting on the previous kthread and waking up the next one.
> > Each kthread, after being awakened, checks a variable that its waker
> > sets just before the wakeup. Have another kthread check for hangs.
> >
> > Possibly introduce timeouts and random delays to stir things up a bit.
> >
> > But maybe such a test already exists. Does anyone know of one? I don't
> > see anything obvious.
> >
>
> Your waketorture patchset[1] seems to be something similar, at least a
> good start ;-)
Glad I could help! ;-)
> As we don't know which kind of scenario will trigger the problem easily,
> I will play around with different ones, and hopefully we can find a way.
Makes sense, please let me know how it goes!
Thanx, Paul
> Regards,
> Boqun
>
> [1]: https://marc.info/?l=linux-kernel&m=146602969518960
>
> > Interested?
> >
> > Thanx, Paul
> >
> [...]
next prev parent reply other threads:[~2017-06-16 3:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 3:25 [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up Krister Johansen
2017-06-09 7:19 ` Peter Zijlstra
2017-06-09 12:45 ` Paul E. McKenney
2017-06-13 23:23 ` Steven Rostedt
2017-06-13 23:42 ` Paul E. McKenney
2017-06-14 1:15 ` Steven Rostedt
2017-06-14 3:58 ` Paul E. McKenney
2017-06-14 13:10 ` Steven Rostedt
2017-06-14 15:02 ` Steven Rostedt
2017-06-14 16:25 ` Krister Johansen
2017-06-15 4:18 ` Boqun Feng
2017-06-15 17:56 ` Paul E. McKenney
2017-06-16 1:07 ` Boqun Feng
2017-06-16 3:09 ` Paul E. McKenney [this message]
2017-08-10 12:10 ` [tip:locking/core] sched/wait: Remove the lockless swait_active() check in swake_up*() tip-bot for Boqun Feng
2017-06-14 15:55 ` [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up Paul E. McKenney
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=20170616030914.GM3721@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=kjlx@templeofstupid.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.