From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932471AbbDMQcK (ORCPT <rfc822;w@1wt.eu>);
	Mon, 13 Apr 2015 12:32:10 -0400
Received: from mail-wg0-f53.google.com ([74.125.82.53]:36210 "EHLO
	mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932162AbbDMQcH (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 13 Apr 2015 12:32:07 -0400
Date: Mon, 13 Apr 2015 18:32:02 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: rusty@rustcorp.com.au, mathieu.desnoyers@efficios.com, oleg@redhat.com,
        paulmck@linux.vnet.ibm.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 <aarcange@redhat.com>,
        David Woodhouse <David.Woodhouse@intel.com>,
        Rik van Riel <riel@redhat.com>, Michel Lespinasse <walken@google.com>
Subject: Re: [PATCH v5 05/10] seqlock: Better document
 raw_write_seqcount_latch()
Message-ID: <20150413163201.GC6040@gmail.com>
References: <20150413141126.756350256@infradead.org>
 <20150413141213.492831596@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150413141213.492831596@infradead.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Peter Zijlstra <peterz@infradead.org> wrote:

> +/**
>   * raw_write_seqcount_latch - redirect readers to even/odd copy
>   * @s: pointer to seqcount_t
> + *
> + * The latch technique is a multiversion concurrency control method that allows
> + * queries during non atomic modifications. If you can guarantee queries never
> + * interrupt the modification -- e.g. the concurrency is strictly between CPUs
> + * -- you most likely do not need this.

Speling nit:

 triton:~/tip> git grep -i 'non-atomic' | wc -l
 160
 triton:~/tip> git grep -i 'non atomic' | wc -l
 21

so I guess 'non-atomic' wins?

> + *
> + * Where the traditional RCU/lockless data structures rely on atomic
> + * modifications to ensure queries observe either the old or the new state the
> + * latch allows the same for non atomic updates. The trade-off is doubling the
> + * cost of storage; we have to maintain two copies of the entire data
> + * structure.

s/non atomic/non-atomic

> + * 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().)

Thanks,

	Ingo