Re: [B.A.T.M.A.N.] [PATCH] 32bit sequence number and TTL for broadcasts

[Sven Eckelmann <sven.eckelmann@gmx.de>]

[-- Attachment #1: Type: Text/Plain, Size: 2624 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]