Messages in this thread | | | Date | Wed, 12 Nov 2014 11:10:52 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH] arch: Introduce read_acquire() |
| |
On Tue, Nov 11, 2014 at 12:45:23PM -0800, Alexander Duyck wrote: > > On 11/11/2014 11:40 AM, Linus Torvalds wrote: > >On Tue, Nov 11, 2014 at 10:57 AM, <alexander.duyck@gmail.com> wrote: > >> > >> > >>On reviewing the documentation and code for smp_load_acquire() it occurred > >>to me that implementing something similar for CPU <-> device interaction > >>would be worth while. This commit provides just the load/read side of this > >>in the form of read_acquire(). > > > >So I don't hate the concept, but. there's a couple of reasons to think > >this is broken. > > > >One is just the name. Why do we have "smp_load_acquire()", but then > >call the non-smp version "read_acquire()"? That makes very little > >sense to me. Why did "load" become "read"? > > The idea behind read vs load in the name was because smp_load_acquire is > using a full smp_mb() whereas this just falls back to rmb() for the cases it > is dealing with. My main conern is that a full memory barrier would be more > expensive so I didn't want to give the idea that this is as completed as > smp_load_acquire(). The read_acquire() call is not strictly enforcing any > limitations on writes/stores, although there are a few cases where the > barriers used do leak that functionality over as a side-effect.
Then I object. We should not name it acquire if it does not in fact provides acquire semantics.
Memory ordering is hard enough, we don't need random weird semantics mixed in just because.
| |