[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150413191750.GK23123@twins.programming.kicks-ass.net>
Date: Mon, 13 Apr 2015 21:17:50 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: rusty@...tcorp.com.au, mathieu.desnoyers@...icios.com,
oleg@...hat.com, paulmck@...ux.vnet.ibm.com,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
andi@...stfloor.org, rostedt@...dmis.org, tglx@...utronix.de,
laijs@...fujitsu.com, linux@...izon.com,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <David.Woodhouse@...el.com>,
Rik van Riel <riel@...hat.com>,
Michel Lespinasse <walken@...gle.com>
Subject: Re: [PATCH v5 05/10] seqlock: Better document
raw_write_seqcount_latch()
On Mon, Apr 13, 2015 at 06:32:02PM +0200, Ingo Molnar wrote:
>
> 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);
>
So in the actual code we use raw_read_seqcount() which includes the rmb.
This is true for the existing __ktime_get_fast_ns() as we as the new
latch_tee_find().
Should we look at introducing yet another seq primitive?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists