Messages in this thread |  | | | Date | Fri, 17 Aug 2007 19:06:20 +0530 (IST) | | From | Satyam Sharma <> | | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote: > > > On Fri, 17 Aug 2007, Nick Piggin wrote: > > > > > Because they should be thinking about them in terms of barriers, over > > > which the compiler / CPU is not to reorder accesses or cache memory > > > operations, rather than "special" "volatile" accesses. > > > > This is obviously just a taste thing. Whether to have that forget(x) > > barrier as something author should explicitly sprinkle appropriately > > in appropriate places in the code by himself or use a primitive that > > includes it itself. > > That's not obviously just taste to me. Not when the primitive has many > (perhaps, the majority) of uses that do not require said barriers. And > this is not solely about the code generation (which, as Paul says, is > relatively minor even on x86).
See, you do *require* people to have to repeat the same things to you!
As has been written about enough times already, and if you followed the discussion on this thread, I am *not* proposing that atomic_read()'s semantics be changed to have any extra barriers. What is proposed is a different atomic_read_xxx() variant thereof, that those can use who do want that. Now whether to have a kind of barrier ("volatile", whatever) in the atomic_read_xxx() itself, or whether to make the code writer himself to explicitly write the order(x) appropriately in appropriate places in the code _is_ a matter of taste.
> > That's definitely the point, why not. This is why "barrier()", being > > heavy-handed, is not the best option. > > That is _not_ the point [...]
Again, you're requiring me to repeat things that were already made evident on this thread (if you follow it).
This _is_ the point, because a lot of loops out there (too many of them, I WILL NOT bother citing file_name:line_number) end up having to use a barrier just because they're using a loop-exit-condition that depends on a value returned by atomic_read(). It would be good for them if they used an atomic_read_xxx() primitive that gave these "volatility" semantics without junking compiler optimizations for other memory references.
> because there has already been an alternative posted
Whether that alternative (explicitly using forget(x), or wrappers thereof, such as the "order_atomic" you proposed) is better than other alternatives (such as atomic_read_xxx() which includes the volatility behaviour in itself) is still open, and precisely what we started discussing just one mail back.
(The above was also mostly stuff I had to repeated for you, sadly.)
> that better conforms with Linux barrier > API and is much more widely useful and more usable.
I don't think so.
(Now *this* _is_ the "taste-dependent matter" that I mentioned earlier.)
> If you are so worried > about > barrier() being too heavyweight, then you're off to a poor start by wanting to > add a few K of kernel text by making atomic_read volatile.
Repeating myself, for the N'th time, NO, I DON'T want to make atomic_read have "volatile" semantics.
> > > because as I also mentioned, the logical extention > > > to Linux's barrier API to handle this is the order(x) macro. Again, not > > > special volatile accessors. > > > > Sure, that forget(x) macro _is_ proposed to be made part of the generic > > API. Doesn't explain why not to define/use primitives that has volatility ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > semantics in itself, though (taste matters apart). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > If you follow the discussion.... You were thinking of a reason why the > semantics *should* be changed or added, and I was rebutting your argument > that it must be used when a full barrier() is too heavy (ie. by pointing > out that order() has superior semantics anyway).
Amazing. Either you have reading comprehension problems, or else, please try reading this thread (or at least this sub-thread) again. I don't want _you_ blaming _me_ for having to repeat things to you all over again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |