"David Laight" wrote on 11/01/2013 06:25:29 PM:
> gcc will do unexpected memory accesses for bit fields that are
> adjacent to volatile data.
> In particular it may generate 64bit sized (and aligned) RMW cycles
> when accessing bit fields.
> And yes, this has caused real problems.
Thanks, I am aw
"Paul E. McKenney" wrote on 10/31/2013
05:25:43 PM:
> I really don't care about "fair" -- I care instead about the kernel
> working reliably.
Though I don't see how putting a memory barrier without deep understanding
why it is needed helps kernel reliability, I do agree that reliability
is more
"Paul E. McKenney" wrote on 10/31/2013
08:40:15 AM:
> > void ubuf_read(void)
> > {
> >u64 head, tail;
> >
> >tail = ACCESS_ONCE(ubuf->tail);
> >head = ACCESS_ONCE(ubuf->head);
> >
> >/*
> > * Ensure we read the buffer boundaries before the actual buffer
> > * data...
> >
"Paul E. McKenney" wrote on 10/31/2013
08:16:02 AM:
> > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > around
> > @head read.
Just to be sure, that we are talking about the same code - I was
considering
ACCESS_ONCE() around @tail in point AAA in the following example
"David Laight" wrote on 10/31/2013 02:28:56 PM:
> So even though the wmb() in the writer ensures the writes are correctly
> ordered, the reader can read the old value from the second location from
> its local cache.
In case of circular buffer, the only thing that producer reads is @tail,
and not
"Paul E. McKenney" wrote on 10/31/2013
06:32:58 AM:
> If you want to play the "omit memory barriers" game, then proving a
> negative is in fact the task before you.
Generally it is not fair. Otherwise, anyone could put an smp_mb() at a
random place, and expect others to "prove" that it is not ne
Peter Zijlstra wrote on 10/30/2013 05:39:31 PM:
> Although I suppose speculative reads are allowed -- they don't have the
> destructive behaviour speculative writes have -- and thus we could in
> fact get reorder issues.
I agree.
>
> But since it is still a dependent load in that we do that @ta
Peter Zijlstra wrote on 10/30/2013 01:25:26 PM:
> Also, I'm not entirely sure on C, that too seems like a dependency, we
> simply cannot read the buffer @tail before we've read the tail itself,
> now can we? Similarly we cannot compare tail to head without having the
> head read completed.
No, t
"Paul E. McKenney" wrote on 10/30/2013
11:27:25 AM:
> If you were to back up that insistence with a description of the
orderings
> you are relying on, why other orderings are not important, and how the
> important orderings are enforced, I might be tempted to pay attention
> to your opinion.
>
>
Oleg Nesterov wrote on 10/28/2013 10:17:35 PM:
> mb(); // : do we really need it? I think yes.
Oh, it is hard to argue with feelings. Also, it is easy to be on
conservative side and put the barrier here just in case.
But I still insist that the barrier is redundant in your exampl
> From: Frederic Weisbecker
>
> 2013/10/25 Peter Zijlstra :
> > On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
> > I would argue for
> >
> > READ ->data_tail READ ->data_head
> > smp_rmb() (A) smp_rmb() (C)
> > WRITE $d
Peter Zijlstra wrote on 10/25/2013 07:37:49 PM:
> I would argue for:
>
> READ ->data_tail READ ->data_head
> smp_rmb() (A) smp_rmb() (C)
> WRITE $data READ $data
> smp_wmb() (B) smp_mb() (D)
> STORE ->data_headWRITE ->data_tail
See below.
Michael Neuling wrote on 10/23/2013 02:54:54 AM:
>
> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> index cd55144..95768c6 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -87,10 +87,10 @@ again:
>goto out;
>
> /
13 matches
Mail list logo
