Messages in this thread | | | Date | Tue, 14 Jan 2014 10:25:16 -0500 | From | Waiman Long <> | Subject | Re: [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock() |
| |
On 01/14/2014 06:03 AM, Peter Zijlstra wrote: > On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote: >>> Peter, >>> >>> I found out that the build failure was caused by the fact that the >>> __native_word() macro (used internally by compiletime_assert_atomic()) >>> allows only a size of 4 or 8 for x86-64. The data type that I used is a >>> byte. Is there a reason why byte and short are not considered native? >> It seems likely it was implemented like that since there was no existing >> need; long can be relied on as the largest native type, so this should >> suffice and works here: > There's Alphas that cannot actually atomically adres a byte; I do not > konw if Linux cares about them, but if it does, we cannot in fact rely > on this in generic primitives like this.
Thank for the explanation.
Can we allow architectural override of __native_word() macro? Like
#ifdef __arch_native_word #define __native_word(t) __arch_native_word(t) #else #define __native_word(t) (sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long)) #endif
In this way, we can allow x86 to support byte-based atomic type while restricting the generic macro to int and long only. I will also modify the code to use cmpxchg() when byte is not an atomic type.
-Longman
| |