lkml.org 
[lkml]   [2015]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 05/10] seqlock: Better document raw_write_seqcount_latch()

* 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


\
 
 \ /
  Last update: 2015-04-13 19:01    [W:0.239 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site