From: Peter Zijlstra <peterz@infradead.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics
Date: Tue, 15 Sep 2015 11:55:12 +0200 [thread overview]
Message-ID: <20150915095512.GA18673@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150915094949.GA16853@twins.programming.kicks-ass.net>
On Tue, Sep 15, 2015 at 11:49:49AM +0200, Peter Zijlstra wrote:
> On Mon, Sep 14, 2015 at 02:08:06PM -0700, Davidlohr Bueso wrote:
> > On Mon, 14 Sep 2015, Peter Zijlstra wrote:
> >
> > >On Mon, Sep 14, 2015 at 12:37:23AM -0700, Davidlohr Bueso wrote:
> > >> /*
> > >>+ * Atomically grab the task. If ->wake_q is non-nil (failed cmpxchg)
> > >>+ * then the task is already queued (by us or someone else) and will
> > >>+ * get the wakeup due to that.
> > >> *
> > >>+ * Use acquire semantics to add the next pointer, which pairs with the
> > >>+ * write barrier implied by the wakeup in wake_up_list().
> > >> */
> > >>+ if (cmpxchg_acquire(&node->next, NULL, WAKE_Q_TAIL))
> > >> return;
> > >>
> > >> get_task_struct(task);
> > >
> > >I'm not seeing a _why_ on the acquire semantics. Not saying the patch is
> > >wrong, just saying I want words on why acquire is correct.
> >
> > Well, I was just taking advantage of removing the upper barrier. Considering
> > that the formal semantics, you are right that we need not actual acquire per-se
> > (ie for node->next) but instead merely ensure a barrier in wake_q_add(). This is
> > kind of why I had hinted of going full _relaxed(). We could also rephrase the
> > comment, something like:
> >
> > * Use ACQUIRE semantics to add the next pointer, such that
> > * wake_q_add() implies a full barrier. This pairs with the
> > * write barrier implied by the wakeup in wake_up_list().
> > */
> >
> > What do you think?
>
> Still befuddled. I'm thinking that if you want to remove a barrier,
> you'd remove that second and keep the first. That is RELEASE.
>
> That way, you know the stores prior to the wake queue are done by the
> time you observe the queued entry, and therefore (transitively) know
> those stores are done by the time you do the actual wakeup.
>
> Two issues with that though; firstly RELEASE is not actually guaranteed
> to be transitive -- now the only arch that does not implement it with a
> full barrier is ARGH64, so we could just ask Will, but I'm not sure its
> 'good' to start relying on this.
Never mind, the PPC people will implement this with lwsync and that is
very much not transitive IIRC.
That said, you could do:
smp_mb__before_atomic();
cmpxchg_relaxed();
Which would still be a full barrier and therefore transitive. However
this point still stands:
> Secondly, the wake queues are not concurrent, they're in context, so I
> don't see ordering matter at all. The only reason its a cmpxchg() is
> because there is the (small) possibility of two contexts wanting to wake
> the same task, and we use task_struct storage for the queue.
I don't think we need _any_ barriers here, unless we have concurrent
users of the wake queues (or want to allow any, do we?).
next prev parent reply other threads:[~2015-09-15 9:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 7:37 [PATCH -tip 1/3] locking/qrwlock: Rename ->lock to ->wait_lock Davidlohr Bueso
2015-09-14 7:37 ` [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics Davidlohr Bueso
2015-09-14 12:32 ` Peter Zijlstra
2015-09-14 21:08 ` Davidlohr Bueso
2015-09-15 9:49 ` Peter Zijlstra
2015-09-15 9:55 ` Peter Zijlstra [this message]
2015-09-15 12:41 ` Paul E. McKenney
2015-09-15 12:48 ` Peter Zijlstra
2015-09-15 14:09 ` Paul E. McKenney
2015-09-15 14:14 ` Peter Zijlstra
2015-09-15 15:34 ` Paul E. McKenney
2015-09-15 16:30 ` Peter Zijlstra
2015-09-15 17:09 ` Paul E. McKenney
2015-09-18 21:41 ` Paul E. McKenney
2015-09-21 9:22 ` Martin Schwidefsky
2015-09-22 10:27 ` Martin Schwidefsky
2015-09-22 12:23 ` Boqun Feng
2015-09-22 12:51 ` Martin Schwidefsky
2015-09-22 13:29 ` Boqun Feng
2015-09-22 14:33 ` Martin Schwidefsky
2015-09-22 15:28 ` Paul E. McKenney
2015-09-23 6:43 ` Martin Schwidefsky
2015-09-25 21:30 ` Paul E. McKenney
2015-09-15 19:49 ` Davidlohr Bueso
2015-09-16 9:01 ` Peter Zijlstra
2015-09-14 7:37 ` [PATCH -tip 3/3] locking/osq: Relax atomic semantics Davidlohr Bueso
2015-09-18 8:50 ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2015-09-18 8:50 ` [tip:locking/core] locking/qrwlock: Rename ->lock to ->wait_lock tip-bot for Davidlohr Bueso
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=20150915095512.GA18673@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--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.