Subject: Re: hppa alignment restrictions on __cpu_simple_lock_t
To: Nick Hudson <skrll@netbsd.org>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/28/2007 12:21:49
--s/l3CgOIzMHHjg/5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2007 at 03:12:31PM +0000, Christos Zoulas wrote:
> In article <200706271155.35230.skrll@netbsd.org>,
> Nick Hudson  <skrll@netbsd.org> wrote:
> >-=3D-=3D-=3D-=3D-=3D-
> >
> >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=
=20
> >aligned word to act upon (use of an unaligned word is undefined). This=
=20
> >presents a problem with __cpu_simple_lock_t where this alignment restric=
tion=20
> >needs to be observed.
> >
> >There are a couple of potential solutions. The first, and the one I've=
=20
> >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 t=
he=20
> >aligned word. New inlines __SIMPLE_LOCKED_P and __SIMPLE_UNLOCKED_P are=
=20
> >provided to replace the current comparisons to __SIMPLE_LOCKED and=20
> >__SIMPLE_UNLOCKED. Also, __cpu_simple_lock_{set,clear} are provided for=
=20
> >the !MP case.
> >
> >The second potential solution is to specify the alignment restriction on=
 the=20
> >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 correc=
tly=20
> >aligned pointers. Memory allocators in both kernel and userland (as=20
> >__cpu_simple_lock_t is used in libpthread). I'm not sure this is workabl=
e and=20
> >is definitely wasteful of memory.
> >
> >Thoughts?
>=20
> 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.

Agreed. This solution sounds less wastefull.

Take care,

Bill

--s/l3CgOIzMHHjg/5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGhApMWz+3JHUci9cRAgd4AJ402TP0Qw5gySzx7vQywuMW7/EP9gCfbpnY
MJ+nywMzWKsHxKOaiC6qWaY=
=DUDk
-----END PGP SIGNATURE-----

--s/l3CgOIzMHHjg/5--