On Thu, 19 Jun 2014, Tejun Heo wrote: > Again, data dependency barrier is noop in all in-use archs.
A barrier limits what the compiler can do. > > Remote write events are contrary to that design and are exceedingly rare. > > An IPI is justifiable for such a rare event. At least in my use cases I > > have always found that to be sufficient. Well, I designed the data > > structures in a way that made this possible because of the design criteria > > that did not allow me remote write access to other processors per cpu > > data. > > You're repeatedly getting wayside in the discussion. What are you > suggesting? Sending IPIs on each percpu allocation? No this is about sending an IPI if you want to modify the percpu data of another process. There was a mentionig of code that modifies the per cpu data of another processor? > Again, I'm leaning towards just clarifying the init write ownership to > the allocating CPU as that seems the most straight forward way to deal > with it, but please stop brining up the raw performance thing. Nobody > is doing anything to that. It's not relevant in the discussion. Ok sounds good. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
