[parisc-linux] [RFC] rewrite kernel spinlock code to work better with gcc

[John David Anglin]

> +/* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data,
> +   and GCC only guarantees 8-byte alignment for stack locals, we can't
> +   be assured of 16-byte alignment for atomic lock data even if we
> +   specify "__attribute ((aligned(16)))" in the type declaration.  So,
> +   we use a struct containing an array of four ints for the atomic lock
> +   type and dynamically select the 16-byte aligned int from the array
> +   for the semaphore.  */
> +#define __PA_LDCW_ALIGNMENT 16
> +#define __ldcw_align(a) ({ \
> +  unsigned long __ret = (unsigned long) a;                     		\
> +  __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) & ~(__PA_LDCW_ALIGNMENT - 1); \
> +  (unsigned int *) __ret;                                               \
> +})

Change cast to "volatile unsigned int *".

>  typedef struct {
> -	volatile unsigned int __attribute__((aligned(16))) lock;
> +	volatile unsigned int lock[4];
>  } spinlock_t;
>  #endif

Is the struct necessary?  For example,

  typedef volatile unsigned int spinlock_t[4];

I believe that there are situations where the rest of the cache line
holding the active lock word should not be used.  The PA 1.x document
says

  When using semaphores to synchonize with I/O, care must be taken
  in placing other information in the same cache line as the semaphore.
  Data which is writeable can only be placed in the same cache line
  as a semaphore if access to write the data is controlled by the
  semaphore.

I think this restriction only applies to semaphores used both by
I/O and CPU processors, and it's not a concern for semaphores used
solely by CPU processors.  If we have locks used by I/O processors
and they are stack allocated, then some extra padding would appear
to be needed for these locks.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)