[head tinderbox] failure on sparc64/sun4v

[Robert Watson]

On Wed, 3 Jun 2009, Eygene Ryabinkin wrote:

>> This seems to be related to the recent NETISR changes, namely, the
>> addition of the pc_netisr member to the struct pcpu:
>>   http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u
>>
>> I am not sure how large (void *) is on sun4v, but it seems to me
>> that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h
>             ^^^^^^^^^^^^
> Sorry, eight bytes long: wrote 4, but really meant 8 ;))
>
>> should be compensated for this change.  Something like
>> -----
>> #ifdef KTR
>> #define	PCPU_MD_FIELDS_PAD	(3 - (PCPU_NAME_LEN + 7) / 8)
>> #else
>> #define	PCPU_MD_FIELDS_PAD	3
>> #endif
>> -----
>> though I am not very sure about KTR's case.
>
> KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just 
> now we won't be able to reach this with the current definition for 
> PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative 
> and that's bad.
>
> The attached patch should fix this (although I have no sun4v to test on, so 
> take it with a grain of salt).
>
> By the way, having looked at sys/sys/pcpu.h, I see that there are parts of 
> 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never 
> compensated with padding in PCPU_MD_FIELDS for sun4v.  Is KTR_PERCPU 
> constant for sun4v (inexisting or defined everytime) or I am missing 
> something?

Is there a reason not just to use __aligned(64) or the like on the first entry 
of the MD PCPU structure for sun4v to avoid future MI pcpu changes from 
causing similar discomfort for the MD pcpu parts?  Also, do we know why these 
alignment/sizing requirements exist for struct pcpu on sun4v but not other 
platforms?  If this is about packing pcpu structures into properly aligned 
cache lines, again __aligned() might be the right approach to take...

Robert N M Watson
Computer Laboratory
University of Cambridge