Subject: Re: hppa alignment restrictions on __cpu_simple_lock_t
To: None <tech-kern@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-kern
Date: 06/27/2007 15:12:31
In article <200706271155.35230.skrll@netbsd.org>,
Nick Hudson  <skrll@netbsd.org> wrote:
>-=-=-=-=-=-
>
>Hi,
>
>It won't come as a surprise to a lot of you that hppa is special.
>
>The ldcw (load and clear word) instruction on PA 1.1 requires a 16 byte 
>aligned word to act upon (use of an unaligned word is undefined). This 
>presents a problem with __cpu_simple_lock_t where this alignment restriction 
>needs to be observed.
>
>There are a couple of potential solutions. The first, and the one I've 
>implemented in the attached patch, is to define
>
>	typedef volatile struct {
>		volatile unsigned long csl_lock[4];
>	} __cpu_simple_lock_t;
>
>and update the functions acting on the __cpu_simple_lock_t to pick out the 
>aligned word. New inlines __SIMPLE_LOCKED_P and __SIMPLE_UNLOCKED_P are 
>provided to replace the current comparisons to __SIMPLE_LOCKED and 
>__SIMPLE_UNLOCKED. Also, __cpu_simple_lock_{set,clear} are provided for 
>the !MP case.
>
>The second potential solution is to specify the alignment restriction on the 
>struct, e.g.
>
>	typedef struct {
>		volatile unsigned long csl_lock;
>	} __cpu_simple_lock_t __aligned(16);
>
>but this places requirement on memory allocators to always return correctly 
>aligned pointers. Memory allocators in both kernel and userland (as 
>__cpu_simple_lock_t is used in libpthread). I'm not sure this is workable and 
>is definitely wasteful of memory.
>
>Thoughts?

You do what you have to do. I agree that your proposed solution is better
since the use of locks is limited, so it is less wasteful than making
all allocators return properly aligned memory.

christos