> [I missed this followup, other stuff] > > On Mon, Oct 23, 2017 at 03:41:49PM +0200, Peter Zijlstra wrote: > > On Sat, Oct 21, 2017 at 10:21:11AM +1100, Dave Chinner wrote: > > > On Fri, Oct 20, 2017 at 02:07:53PM +0300, Elena Reshetova wrote: > > > IMO, that makes it way too hard to review sanely for code that: > > > > > > a) we already know works correctly > > > > But how do you know if you have unknown ordering requirements? > > Because back when it was converted to atomic-based object reference > counts, I went through all the memory-barriers.txt stuff to make > sure it was OK. That was years ago, and I've forgotten it all and > the life-cycle constaints that lead us to use atomics in this > manner. > > Now, I've got to go determine what the difference between atomic and > refcounts are and work them out myself because nobody has documented > it. And I have to go look at all the commit logs to work out in that > has any effect on the objects using the atomics, because that's no > longer in my head. There probably isn't an issue here, but such > changes are not done without review, and that's what is needed to > review the change. > > That's the problem here - I have to work out what the differences in > ordering constraints between refcounts and atomics are myself > because it's not actually documented anywhere for reviewiers to > understand. That's a significant burden to put on a reviewer for > what is supposed to be a "no-op" change.
The memory ordering changes are currently documented in refcount.c file itself, but I agree that we should try to provide more information. That's why we are having this separate thread now going and searching for suitable examples and more elaborate explanation. So, hopefully very soon we will end up with having what you are asking for. Best Regards, Elena. > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com
