Re: [PATCH v5 05/10] seqlock: Better document raw_write_seqcount_latch()

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/