From: Davidlohr Bueso <dave@stgolabs.net> To: Peter Zijlstra <peterz@infradead.org> Cc: Waiman Long <Waiman.Long@hpe.com>, Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org, x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, Jason Low <jason.low2@hp.com>, Dave Chinner <david@fromorbit.com>, Scott J Norton <scott.norton@hpe.com>, Douglas Hatch <doug.hatch@hpe.com> Subject: Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier Date: Wed, 15 Jun 2016 11:56:11 -0700 [thread overview] Message-ID: <20160615185611.GE2094@linux-80c1.suse> (raw) In-Reply-To: <20160615184007.GW30921@twins.programming.kicks-ass.net> On Wed, 15 Jun 2016, Peter Zijlstra wrote: >On Wed, Jun 15, 2016 at 11:27:24AM -0700, Davidlohr Bueso wrote: >> On Wed, 15 Jun 2016, Peter Zijlstra wrote: >> >> >In any case, its fairly simple to cure, just add >> >smp_acquire__after_ctrl_dep() at the end. If we bail because >> >need_resched() we don't need the acquire I think. >> >> I was just considering this for your smp_cond_acquire/smp_cond_load_acquire > >Right, so that need_resched break makes that a bit awkward. Not to >mention the cpu_relaxed() vs cpu_relaxed_lowlatency() difference. Oh sure, I was merely refering to the ordering semantics, not the calls themselves -- although at some point, as archs begin to port locking/core optimizations, we _will_ need the variants for dealing with '_lowlatency'. > >> rework, so yeah I guess an smp_acquire__after_ctrl_dep would be a nice >> compromise. >> >> However, I was always under the impression that races with node->locked were >> rather harmless (as indicated in the mentioned commit) -- which is why ->locked >> are simple load/stores, with the exception of the unqueueing -- but yeah, that's >> not even paired. > >Yeah, see a few patches further in this series, where he guards a >variables with the osq_lock. *sigh*
WARNING: multiple messages have this Message-ID (diff)
From: Davidlohr Bueso <dave@stgolabs.net> To: Peter Zijlstra <peterz@infradead.org> Cc: Waiman Long <Waiman.Long@hpe.com>, Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org, x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-arch@vger.kernel.org, Jason Low <jason.low2@hp.com>, Dave Chinner <david@fromorbit.com>, Scott J Norton <scott.norton@hpe.com>, Douglas Hatch <doug.hatch@hpe.com> Subject: Re: [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier Date: Wed, 15 Jun 2016 18:56:11 +0000 [thread overview] Message-ID: <20160615185611.GE2094@linux-80c1.suse> (raw) In-Reply-To: <20160615184007.GW30921@twins.programming.kicks-ass.net> On Wed, 15 Jun 2016, Peter Zijlstra wrote: >On Wed, Jun 15, 2016 at 11:27:24AM -0700, Davidlohr Bueso wrote: >> On Wed, 15 Jun 2016, Peter Zijlstra wrote: >> >> >In any case, its fairly simple to cure, just add >> >smp_acquire__after_ctrl_dep() at the end. If we bail because >> >need_resched() we don't need the acquire I think. >> >> I was just considering this for your smp_cond_acquire/smp_cond_load_acquire > >Right, so that need_resched break makes that a bit awkward. Not to >mention the cpu_relaxed() vs cpu_relaxed_lowlatency() difference. Oh sure, I was merely refering to the ordering semantics, not the calls themselves -- although at some point, as archs begin to port locking/core optimizations, we _will_ need the variants for dealing with '_lowlatency'. > >> rework, so yeah I guess an smp_acquire__after_ctrl_dep would be a nice >> compromise. >> >> However, I was always under the impression that races with node->locked were >> rather harmless (as indicated in the mentioned commit) -- which is why ->locked >> are simple load/stores, with the exception of the unqueueing -- but yeah, that's >> not even paired. > >Yeah, see a few patches further in this series, where he guards a >variables with the osq_lock. *sigh*
next prev parent reply other threads:[~2016-06-15 18:56 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-14 22:48 [RFC PATCH-tip v2 0/6] locking/rwsem: Enable reader optimistic spinning Waiman Long 2016-06-14 22:48 ` Waiman Long 2016-06-14 22:48 ` [RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier Waiman Long 2016-06-14 22:48 ` Waiman Long 2016-06-15 8:04 ` Boqun Feng 2016-06-15 8:04 ` Boqun Feng 2016-06-15 17:18 ` Peter Zijlstra 2016-06-15 17:18 ` Peter Zijlstra 2016-06-15 19:01 ` Waiman Long 2016-06-15 19:01 ` Waiman Long 2016-06-15 19:01 ` Waiman Long 2016-06-16 2:19 ` Boqun Feng 2016-06-16 2:19 ` Boqun Feng 2016-06-16 10:16 ` Will Deacon 2016-06-16 10:16 ` Will Deacon 2016-06-16 21:35 ` Waiman Long 2016-06-16 21:35 ` Waiman Long 2016-06-16 21:35 ` Waiman Long 2016-06-17 0:48 ` Boqun Feng 2016-06-17 0:48 ` Boqun Feng 2016-06-17 15:26 ` Waiman Long 2016-06-17 15:26 ` Waiman Long 2016-06-17 15:26 ` Waiman Long 2016-06-17 15:45 ` Will Deacon 2016-06-17 15:45 ` Will Deacon 2016-06-17 18:17 ` Waiman Long 2016-06-17 18:17 ` Waiman Long 2016-06-17 18:17 ` Waiman Long 2016-06-18 8:46 ` Boqun Feng 2016-06-18 8:46 ` Boqun Feng 2016-06-20 7:59 ` Will Deacon 2016-06-20 7:59 ` Will Deacon 2016-06-15 16:56 ` Davidlohr Bueso 2016-06-15 16:56 ` Davidlohr Bueso 2016-06-15 17:12 ` Peter Zijlstra 2016-06-15 17:12 ` Peter Zijlstra 2016-06-15 18:27 ` Davidlohr Bueso 2016-06-15 18:27 ` Davidlohr Bueso 2016-06-15 18:40 ` Peter Zijlstra 2016-06-15 18:40 ` Peter Zijlstra 2016-06-15 18:56 ` Davidlohr Bueso [this message] 2016-06-15 18:56 ` Davidlohr Bueso 2016-06-17 1:11 ` Davidlohr Bueso 2016-06-17 1:11 ` Davidlohr Bueso 2016-06-17 14:28 ` Waiman Long 2016-06-17 14:28 ` Waiman Long 2016-06-17 14:28 ` Waiman Long 2016-06-17 16:29 ` Davidlohr Bueso 2016-06-17 16:29 ` Davidlohr Bueso 2016-06-17 16:46 ` Davidlohr Bueso 2016-06-17 16:46 ` Davidlohr Bueso 2016-06-15 19:08 ` Waiman Long 2016-06-15 19:08 ` Waiman Long 2016-06-15 19:08 ` Waiman Long 2016-06-15 20:04 ` Waiman Long 2016-06-15 20:04 ` Waiman Long 2016-06-15 20:04 ` Waiman Long 2016-06-15 21:59 ` Peter Zijlstra 2016-06-15 21:59 ` Peter Zijlstra 2016-06-14 22:48 ` [RFC PATCH-tip v2 2/6] locking/rwsem: Stop active read lock ASAP Waiman Long 2016-06-14 22:48 ` Waiman Long 2016-06-15 17:22 ` Peter Zijlstra 2016-06-15 17:22 ` Peter Zijlstra 2016-06-15 19:17 ` Waiman Long 2016-06-15 19:17 ` Waiman Long 2016-06-15 19:17 ` Waiman Long 2016-06-16 2:14 ` Davidlohr Bueso 2016-06-16 2:14 ` Davidlohr Bueso 2016-06-16 21:25 ` Waiman Long 2016-06-16 21:25 ` Waiman Long 2016-06-16 21:25 ` Waiman Long 2016-06-14 22:48 ` [RFC PATCH-tip v2 3/6] locking/rwsem: Enable count-based spinning on reader Waiman Long 2016-06-14 22:48 ` Waiman Long 2016-06-15 17:38 ` Peter Zijlstra 2016-06-15 17:38 ` Peter Zijlstra 2016-06-15 19:28 ` Waiman Long 2016-06-15 19:28 ` Waiman Long 2016-06-15 19:28 ` Waiman Long 2016-06-14 22:48 ` [RFC PATCH-tip v2 4/6] locking/rwsem: move down rwsem_down_read_failed function Waiman Long 2016-06-14 22:48 ` Waiman Long 2016-06-15 17:40 ` Peter Zijlstra 2016-06-15 17:40 ` Peter Zijlstra 2016-06-15 19:21 ` Waiman Long 2016-06-15 19:21 ` Waiman Long 2016-06-15 19:21 ` Waiman Long 2016-06-14 22:48 ` [RFC PATCH-tip v2 5/6] locking/rwsem: Change RWSEM_WAITING_BIAS for better disambiguation Waiman Long 2016-06-14 22:48 ` Waiman Long 2016-06-15 17:43 ` Peter Zijlstra 2016-06-15 17:43 ` Peter Zijlstra 2016-06-15 19:31 ` Waiman Long 2016-06-15 19:31 ` Waiman Long 2016-06-15 19:31 ` Waiman Long 2016-06-15 21:57 ` Peter Zijlstra 2016-06-15 21:57 ` Peter Zijlstra 2016-06-15 17:45 ` Peter Zijlstra 2016-06-15 17:45 ` Peter Zijlstra 2016-06-15 19:35 ` Waiman Long 2016-06-15 19:35 ` Waiman Long 2016-06-15 19:35 ` Waiman Long 2016-06-14 22:48 ` [RFC PATCH-tip v2 6/6] locking/rwsem: Enable spinning readers Waiman Long 2016-06-14 22:48 ` Waiman Long
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=20160615185611.GE2094@linux-80c1.suse \ --to=dave@stgolabs.net \ --cc=Waiman.Long@hpe.com \ --cc=david@fromorbit.com \ --cc=doug.hatch@hpe.com \ --cc=jason.low2@hp.com \ --cc=linux-alpha@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=scott.norton@hpe.com \ --cc=x86@kernel.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: linkBe 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.