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