Marek Lindner wrote:
On Monday 26 April 2010 04:48:13 Sven Eckelmann wrote:
First thing: it doesn't compile here :( (UML), but I am quite unsure if
this is a UML problem like many other things or a bigger problem.... it seems that it is uml specific as ATOMIC64_INIT and other thingss are defined, but the implementation of specific functions are missing... but this is not the first time such thing happens with uml. Maybe someone with some time can check different openwrt builds.
For example other architecture seems to use the generic implementation of
it: * arm
- parisc
- powerpc
- sh
I think Sven got a point here. It seems that for atomic64_t to work one needs a CPU which supports 64Bit operations otherwise the linux kernel will use its generic implementation.
This is not really true. There are optimized implementation for different cpus which don't have 64 bit atomic operations. But yes, the mentioned architectures doesn't seem to have it or I've just ignored their implementation.
Apparently it uses an array of 16 spinlocks to provide this functionality. I wonder whether this might be a lot of overhead for our needs.
Yes, it uses that array and decides which spinlock to use by hashing the address (probably address & 0xf) - it doesn't use all 16 hashes at the same time. It isn't really perfect when we have a lot of cpus and/or stuff which generates a lot of interrupts and uses atomic64_t. But I don't think we can avoid using spinlocks when we don't use platform optimized atomic*_t.
Furthermore the generic implementation was added recently (as far as I can tell 2.6.30 does not have it) which raises the question of backward compatibility.
Correct, forgot to check in which version this functionality came (so it is not Simon's fault, but mine). The basic problem why it was decided that it is needed to use atomic64_t was that until 2.6.3 atomic_t only provided 24-bit useful bits. This would result in in big caps while checking the seqno (problems for restart detection or other things).
The documentation still states that we can only hope for 24 useful bits in atomic_read. So I would guess that it is maybe the best idea to ask the kernel developers if the statenments in arch/mn10300/include/asm/atomic.h and include/asm-generic/atomic.h are obsolete and 32 useful bits are guaranteed after 2.6.3. Otherwise we have to choose between backward compatibility, spinlock overhead or a magical third option.
Best regards, Sven