From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932689AbbDMRnc (ORCPT ); Mon, 13 Apr 2015 13:43:32 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:43379 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932359AbbDMRna (ORCPT ); Mon, 13 Apr 2015 13:43:30 -0400 Date: Mon, 13 Apr 2015 10:43:23 -0700 From: "Paul E. McKenney" To: Mathieu Desnoyers Cc: Ingo Molnar , Peter Zijlstra , rusty@rustcorp.com.au, oleg@redhat.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de, laijs@cn.fujitsu.com, linux@horizon.com, Andrea Arcangeli , David Woodhouse , Rik van Riel , Michel Lespinasse Subject: Re: [PATCH v5 05/10] seqlock: Better document raw_write_seqcount_latch() Message-ID: <20150413174323.GY23685@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150413141126.756350256@infradead.org> <20150413141213.492831596@infradead.org> <20150413163201.GC6040@gmail.com> <1979415164.29724.1428944899771.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1979415164.29724.1428944899771.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15041317-8236-0000-0000-00000ABA79CD Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 13, 2015 at 05:08:19PM +0000, Mathieu Desnoyers wrote: > ----- Original Message ----- > > > > * Peter Zijlstra wrote: > > > [...] > > > + * The query will have a form like: > > > + * > > > + * struct entry *latch_query(struct latch_struct *latch, ...) > > > + * { > > > + * struct entry *entry; > > > + * unsigned seq, idx; > > > + * > > > + * do { > > > + * seq = latch->seq; > > > + * smp_rmb(); > > > + * > > > + * idx = seq & 0x01; > > > + * entry = data_query(latch->data[idx], ...); > > > + * > > > + * smp_rmb(); > > > + * } while (seq != latch->seq); > > > > Btw., I realize this is just a sample, but couldn't this be written > > more optimally as: > > > > do { > > seq = READ_ONCE(latch->seq); > > smp_read_barrier_depends(); > > > > idx = seq & 0x01; > > entry = data_query(latch->data[idx], ...); > > > > smp_rmb(); > > } while (seq != latch->seq); > > > > Note that there's just a single smp_rmb() barrier: the READ_ONCE() is > > there to make sure GCC doesn't calculate 'idx' from two separate > > reads, but otherwise there's a direct data dependency on latch->seq so > > no smp_rmb() is needed, only a data dependency barrier when doing the > > first lookup AFAICS? > > > > (This doesn't matter on x86 where smp_rmb() is barrier().) > > The latch evolved from seqlock.h, where there was no > data dependency between the sequence counter and the > data read, hence the smp_rmb(). Indeed, there is a > data dependency in the case of the latch, so I think > your approach of READ_ONCE + smp_read_barrier_depends() > is appropriate. A shorthand for READ_ONCE + smp_read_barrier_depends() is the shiny new lockless_dereference(). This helps readability, as it is often non-trivial to work out which accesses smp_read_barrier_depends() is helping to order. Thanx, Paul