On 06/25/2015 12:33 AM, Daniel Vetter wrote: >> In the specific case of bitfields it seems like it would be sufficient >> > to mark the local variables as volatile? Or maybe just use open coded >> > compiler barrier() functions instead, with accompanying documentation. >> > >> > Documentation/memory-barriers.txt is growing more and more interesting >> > over the years (definitely more complicated than when I last added to it!). > Yeah I'm honestly not too concerned about gcc making a mess in the two > cases Chris want's to check something locklessly. It's more for > documentation really so that when you read the code that special lockless > access sticks out. Compiler barrier with a local variable might work, but > the nice thing with ACCESS_ONCE&friends is that they also document exactly > what the thing is you read locklessly. > > Wrt comments: I thought the rule for comments on barriers is to make sure > you don't forget to explain where the other side of the barrier is. Which > very often is totally non-obvious. With lockless access we should have > comments in headers already which locks protect which data (big emphasis > on "should"), and the macros make it clear that lockless tricks are being > played. So not sure what to add in comments. What do you have in mind? Well I think they should document what ordering issue they're trying to resolve. What other code path depends on the specific ordering that the ACCESS_ONCE provides in both of these cases? > Aside: The two users in drm&i915 could all be replaced with READ_ONCE I > think. That would make things a little clearer, but we should still document whether we're trying to make things work vs an interrupt handler, or describe the reordering/folding/optimization we're trying to prevent with the macro that would affect behavior. Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
