Re: [head tinderbox] failure on sparc64/sun4v

On Wednesday 03 June 2009 7:14:38 pm Marcel Moolenaar wrote:
> 
> On Jun 3, 2009, at 1:06 PM, Robert Watson wrote:
> >
> > 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...
> 
> Adding __aligned(xx) doesn't make it aligned. For example,
> malloc(3) only aligns at 16-byte boundaries, so any
> user-space structure that has __aligned(x>16) must manually
> make sure that this is actually the case by over-allocating
> and then adjusting the pointer to an x>16 aligned address.
> Likewise for the kernel, though it's easier in the kernel
> to get something that's page-aligned...
> FYI,

Yes, but struct pcpu is a bit special I think.  The MD code is responsible for 
allocating it (and in at least some cases it just allocates a complete page).  
As long as sun4v allocates struct pcpu on a 64 byte boundary, simply throwing 
__aligned() in will fix it.  Also, since the existing code is just computing 
explicit padding space, it is already assuming the alignment of struct pcpu.  
It is simply implementing __aligned() in a harder-to-maintain way.  It also 
doesn't make any sense the way it is doing it now since it is simply adding 
padding to the end of the structure.  Perhaps it is attempting to round up 
the size of the entire structure?  If so, that can easily be fixed in the MD 
code that allocates the structures by doing 'roundup(sizeof(struct pcpu), N)' 
when allocating the structure.

The comments in pcpu.h seem to imply that it wants a section of the fields in 
the middle to be aligned to a certain boundary in which case I think the 
proper solution is to stick an __aligned() on the first such member and then 
to allocate the structures on a suitable alignment when allocating PCPU 
structures in the MD code.  Presumably it would need the special work when 
allocating these structures even with the current hard-to-maintain padding 
hack.  Again, that hack is no better than __aligned(), just a much bigger 
pain to maintain AFAICT.

-- 
John Baldwin