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@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
